[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Finalized Exceptions
- From: Mark Hamburg <mhamburg@...>
- Date: Fri, 06 Aug 2004 15:34:55 -0700
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