Re: Finalized Exceptions

[Mark Hamburg <mhamburg@...>]

on 8/6/04 4:04 PM, Diego Nehab at diego@tecgraf.puc-rio.br wrote:

>> * protected functions only work if the function itself reports all errors
>> via exceptions. This isn't really a problem, but it is a subtlety in the
>> design that probably should be specifically called out in any documentation
>> about how to program with protected.
> 
> You mean, the finalizer only get's called if the function reports errors
> by exceptions? If so, yes. Otherwise, returning nil, "message" still
> works fine from within protected functions. Maybe I should stress that
> in the LTN.

Actually, there are two things to call out in the documentation:

1. The finalizer only runs in a try construct if the wrapped code uses error
values rather than exceptions.

2. protect expects that any errors from the function being protected will be
reported as exceptions

The second is easy to code to and is simply part of the design pattern. The
first is more subtle since things one might not expect to throw exceptions
can throw.

> 
>> * pcall is hostile to coroutine yields
> 
> Indeed. :o( But this is out of my hands (and I am grateful for that).
> I bet it's hard to work around or the big guys would already have done
> it. :o) Mike let me know about this issue the other day.

I understand the problem and a good work around doesn't come to mind unless
one moved the information from the pcall stack frame off of the C stack and
into something maintained by Lua. That, however, might complicate using
replacement exception mechanisms such as C++ exceptions. If it could be made
to work, though, it might also provide a basis for putting finally support
into the VM. (I was going to say "finalization" but some might say that's
what __gc metamethods provide.)

Mark