>>>>> "Coda" == Coda Highland <chighland@gmail.com> writes:
>> - I'm unsatisfied with the response to Andrew Gierth's comment about
>> ensuring that errors are propagated to the embedder: I think it's
>> crucial to lua's use as an embeddable language
>> I *think* the solution should be that an error in a <toclose> should
>> be immediately rethrown and that other <toclose> statements don't
>> get to run.
Coda> I STRONGLY disagree. The contract is that <toclose> runs no
Coda> matter how the function exits, as long as it does in fact exit.
I also disagree with Daurnimator's solution. I can, just about, work
with the current <toclose> definition by ensuring that the user-supplied
code can't ever create objects with __close metamethods. This is
obviously a serious restriction, but it ensures that the user can't put
arbitrary code into the error recovery path, which is all I need.
What I can't handle is the ignoring of errors in GC.
One solution I'm wondering about (as I hinted at earlier) is whether it
would be sufficient to allow the environment to supply some kind of
function that would be used as a handler for all __gc calls (and maybe
also for __close calls whose errors would otherwise be ignored). (Since
such errors should be rare, the environment might decide to treat them
as fatal, a better option than crashing or corrupting the database.)
--
Andrew.
I think I like that. You can already define a panic handler for errors thrown in an unprotected call. Defining a handler for errors thrown in uncatchable areas would be a good counterpart.
/s/ Adam
