Re: __close and nil error

[Roberto Ierusalimschy <roberto@...>]

> > 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,
isn't it?

-- Roberto