[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Custom extensions to Lua
- From: Rici Lake <lua@...>
- Date: Wed, 10 Aug 2005 18:57:33 -0500
On 10-Aug-05, at 6:02 PM, David Given wrote:
It uses exceptions extensively in order to communicate error states.
they're not cheap in terms of code size, but used properly they can
simplify your logic flow. Another thing I was doing was never
allocating anything if I could possibly help it; I think I use the new
operator once in the entire program. (Although I do use STL containers
a lot.) Since C++ exceptions call destructors, this means that all my
allocation problems basically go away.
The Lua parser is an interesting example of precisely that philosophy,
of course it uses the features Lua provides (like tables) rather than
Hauling the subject bodily back on topic, one of the few issues I have
Lua is that there's no standard for exceptions. There is no consistent
of memory' exception; some parts throw a string, some a number, some
an error code, some return an error string, etc. The other standard
cases are all quite similar.
There are a lot of libraries out there which have not tried to conform
the Lua style, imho. Many of these are just light wrappers around C or
libraries, of course, and have not been reengineered in any way. There
really no excuse for not using a standard Lua mechanism for returning
Having said that, I do agree that:
I do feel strongly that the use of exceptions can very much improve a
and in keeping with the Lua philosophy, it would be a good idea to
standardised framework that application and library writers can use.
this framework should, I think, involve standard exception *names*.
Otherwise, there's no way of knowing if you've caught a standard
One of the interesting things about exceptions is that catching named
exceptions implies a dynamic (i.e. runtime) scope for bindings (to