Re: Proposal: Finally statement of function

[Rici Lake <lua@...>]

On 9-Feb-07, at 10:39 PM, Glenn Maynard wrote:

> I havn't understood all of the details of this idea, since I don't know
> Lua's internals well enough, but what if an error is thrown?  I think
> that's most of the point: to be able to clean up promptly if an error
> happens.
>
> It seems like it couldn't run the finalizer then call the error
> function; errfunc needs to be called at the actual error, for
> backtracing.  In principle, it could call the error handler, then
> call the finalizer before returning to the nearest pcall.

That's exactly what it does (or would do).

This is how Lua works (currently) when an error is thrown:

1) the error function is called immediately when an
error is encountered, so it sees the current stack.

2) Then upvalues are closed back to the last pcall() (or to the
beginning of the stack.) That's necessary because the stack
is about to be popped back to that pcall().

3) Finally, the stack is popped back to the pcall, and control
is returned to the pcall.

That's precisely why I think that the upvalue closure
mechanism can be used as well to implement finalizers.
The proposed finalizer mechanism runs the finalizer during
the upvalue closure sequence, which means it will run
at step 2, above, ensuring that the finalizer executes
before the pcall is returned to.