Re: Finalized Exceptions

[Mark Hamburg <mhamburg@...>]

on 8/6/04 11:31 AM, Diego Nehab at diego@tecgraf.puc-rio.br wrote:

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

You are correct and my note should have reminded me of that. I was thinking
about each of the try clauses, but they don't use pcall except in the event
of an exception. My bad.

A broader concern with the approach is that it uses a delicate balance
between the use of exceptions and error results:

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

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

* pcall is hostile to coroutine yields

This convention also has a bit of trouble if nil is a valid result from a
function, but one can probably work around that in fairly straightforward
ways.

Mark