lua-users home
lua-l archive

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




On 2019-06-11 2:05 p.m., Andrew Gierth 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.)


can't you just use coroutines? what's so special about __close that makes you uncomfortable? does it break hooks just like __gc does? that doesn't seem to make sense, as __close happens deterministically and thus it makes sense to debug __close.