[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: __close and nil error
- From: Roberto Ierusalimschy <roberto@...>
- Date: Tue, 27 Sep 2022 10:31:59 -0300
> > A nil as an error object seems quite unusual. By now, a quite simple
> > solution would be to "normalize" a nil to false when calling __close.
> I imagine it's rare-- though it can be achieved simply by `error()`. On
> the other hand, if you're writing a library, or there is 3rd party code
> invoked within the scope of to-be-closed, you can't really guess what error
> values may be used.
My point about being unusual was only to mean that the normalization
of nil to false would be rare and mostly irrelevant in general.
> Normalizing to false doesn't seem better, as boolean is also a valid error
> value. If it's deemed worth fixing, adding a status arg seems best.
I don't see the relevance of booleans being valid error values. The
point is that __close gets nil if and only if there were no errors. So,
there is a bulletproof (and simple) way to know whether there was an
error, with minimal changes from how it is now. This is what is needed,