Re: Custom extensions to Lua

[Rici Lake <lua@...>]

On 10-Aug-05, at 6:02 PM, David Given wrote:

> It uses exceptions extensively in order to communicate error states. 
> Yes,
> they're not cheap in terms of code size, but used properly they can 
> *vastly*
> simplify your logic flow. Another thing I was doing was never 
> dynamically
> 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 
> quite
> a lot.) Since C++ exceptions call destructors, this means that all my 
> memory
> allocation problems basically go away.

The Lua parser is an interesting example of precisely that philosophy, 
although
of course it uses the features Lua provides (like tables) rather than 
STL.

> Hauling the subject bodily back on topic, one of the few issues I have 
> with
> Lua is that there's no standard for exceptions. There is no consistent 
> 'out
> of memory' exception; some parts throw a string, some a number, some 
> return
> an error code, some return an error string, etc. The other standard 
> failure
> cases are all quite similar.

There are a lot of libraries out there which have not tried to conform 
to
the Lua style, imho. Many of these are just light wrappers around C or 
C++
libraries, of course, and have not been reengineered in any way. There 
is
really no excuse for not using a standard Lua mechanism for returning 
errors.

Having said that, I do agree that:

> I do feel strongly that the use of exceptions can very much improve a 
> program,
> and in keeping with the Lua philosophy, it would be a good idea to 
> provide a
> standardised framework that application and library writers can use. 
> Part of
> this framework should, I think, involve standard exception *names*.
> Otherwise, there's no way of knowing if you've caught a standard 
> exception or
> not.

One of the interesting things about exceptions is that catching named 
exceptions implies a dynamic (i.e. runtime) scope for bindings (to 
exception handlers).