Re: Lua 5.4.0-alpha-rc1 behavior with closing methods errors

[nobody <nobody+lua-list@...>]

On 20/06/2019 13.19, David Heiko Kolf wrote:
> In C# the last error is reported and I actually think that is the 
> right decision.
>
> […]
>
> If the first error is reported I will never even know that there was 
> a second error. And once I fixed the first error, I probably won't 
> see that there is problem with my __close function.

The situation that caused the last error is potentially caused by an
arbitrarily large number of (mis-/un-)handled errors that happened
before that, and the data that your __close has to work with is
arbitrarily insane.  If you want to have a chance to work your way back
to the earlier errors, you'll have to write paranoid (long, unreadable)
code.

Only the first error in the chain is certainly caused by an actual
problem.  All later errors are potentially just interface/invariant
violations caused by the first error, and it's not your(/__close's) job
to navigate the mess caused by interface-/invariant-violating code.

If something's supposed to be a table but isn't, whoever didn't create
that table is to blame, not the __close that amplifies the (previously
silent) error.  (If the table (or subobject, …) creation might fail,
have an .is_valid flag?  Or better yet, don't mark it as <toclose>
before it actually makes sense to close it…)




How would you "fix" this "error" in your example?  I don't see anything
wrong there.

> __close = function( )  z.closed = true  end -- error, z might be nil

If anything, I might add a loud check that z is a table (or
__index-able), but Lua's error message ("attempt to index a nil value")
already says that (and even includes the type of the value, and
potentially its name!) – so a manual check would just add more code to
produce a less informative error message… so actually there is nothing
to fix?  (What am I missing? O.o)

-- nobody