Re: Finalized Exceptions

[Diego Nehab <diego@...>]

Hi,

> * try depends on the code being "wrapped" (not the finalizer) not throwing
> an exception. When seeming harmless code -- t[ k ] for example -- throws an
> exception perhaps because of a metamethod, the finalization logic doesn't
> get run.

Yes. It would be cool if we could trap all errors. Methinks the only way
to do this would be to have the finalizer be associated with the
protect() function, not with the try() function. Just not sure how
something passed to protect() would have access to whatever has to
be finalized. :o/

In the other hand, one of the annoying things is that, during development,
errors end up being trapped by protect() and being returned as strings. :o)

One way to work around this (at a slight cost) is to have the try()
package the error message in a table or something that distinguishes
them from errors thrown by other means. Protect() could then take a
look at the error message that it received and see if it is in the
expected package. If not, it would let the message through because it
wasn't thrown by try().

> * 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.

> * 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.

[]s,
Diego.