Re: Finalized Exceptions

[Diego Nehab <diego@...>]

Hi,

> I just finished reading Diego Nehab's page on "Finalized Exceptions" on the
> Lua Users' Wiki. (http://lua-users.org/wiki/FinalizedExceptions) I like the
> overall approach and something like it might be a good idea for inclusion in
> Lua 5.1. I would add it myself to my version, but I'm cautious about
> namespace clashes.

Hey! I didn't announce that yet. :o)

> * I'm a little unclear as to where the finalized part comes in with respect
> to exceptions -- i.e., the title isn't immediately obvious to me.

It's the fact that you can have a finalizer be called automatically when
there is an exception.

> * The notion of generating a new finalization function and then running
> everything else through it feels a little heavy for coding. Yes, it beats
> many of the present alternatives, but it cries out for an easy way to wrap a
> block of statements in a single try.

The reason I wrote the LTN was to create this kind of discussion.
I actually sent a message with the same content to the list but it
went completely unnotticed.

The try function is the function that actually throws the exceptions. If
every standard library function threw exceptions directly, users would be
forced to always catch them. I wouldn't like this.

With the try() function calls, you can choose when to throw exceptions
and when to use the return values. Notice that if you have your own
exception-throwing auxiliary functions, you don't need to nest them with
calls to try() (but see below).

> * Is my impression correct that try does not work if the code being wrapped
> should happen to throw an exception? In other words, it only works if
> everything is well behaved?

No and yes. If the code being wrapped throws the exceptions itself, the
finalizer called will be the one associated to the try() function that
actually threw the exception somewhere down the call stack. But the
exception will still break the flow until it is caught by a protected
function somewhere up the stack.

For the modules I write, every time a function calls try(), it is the
same try(), so everything works as planned.

> [... snip... ]
> This basically mirrors C++ constructor/destructor error handling semantics.
> It creates exactly as many closures, but it makes fewer calls to pcall.

How so? The only calls to pcall() in the LTN code are implicit in protected
functions. Only the top level function is ever protected, so it's just one
call.

[]s,
Diego.