Re: [ANN] Lua 5.4.0 (alpha-rc1) now available
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: [ANN] Lua 5.4.0 (alpha-rc1) now available
- From: Andrew Gierth <andrew@...>
- Date: 2019年5月31日 20:35:51 +0100
>>>>> "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.