Re: [ANN] Lua 5.4.0 (alpha-rc1) now available

[Andrew Gierth <andrew@...>]

>>>>> "Gé" == Gé Weijers <ge@weijers.org> writes:

 >> I understand that handling errors in GC is tricky, but having a
 >> place where errors are caught and then ignored is a complete
 >> showstopper in an environment where errors MUST be propagated up to
 >> a point where they can be safely handled (and no, this can't be done
 >> inside the __gc method itself).

 Gé> The problem is that there's no 'up' to propagate to. If the GC
 Gé> would throw an error it lands in a random block of code, which
 Gé> means that your code would have to be able to handle any error in
 Gé> any location, and using third-party libraries would be very risky.

But from the perspective of Lua code, errors _can_ be thrown in any
location - consider "out of memory" as an example - and they propagate
up to a well-defined place, i.e. the nearest enclosing pcall.

 Gé> This problem is not limited to Lua,

I could not care less about other languages.

 Gé> Code called from __gc should only release resources and such, and
 Gé> handle its own errors.

But I am working in an environment - embedding Lua into an existing
large and complex program, namely the PostgreSQL backend - which has its
own rules about error handling that simply do not allow this. In
particular, I can't guarantee that closing a database cursor won't throw
an error, and if it does, then I can't allow execution of arbitrary Lua
code until after the subtransaction has been cleaned up (which requires
propagating the error).

 Gé> The new generational GC may delay the call to __gc for a *long*
 Gé> time,

This doesn't matter to me.

 Gé> so if you can use the new __close metamethod you probably should
 Gé> use that instead.

There is no "instead". __gc and __close serve very different purposes.

-- 
Andrew.