lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]




On Tue, Jun 11, 2019 at 12:05 PM Andrew Gierth <andrew@tao11.riddles.org.uk> wrote:
>>>>> "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