It was thus said that the Great Jorge once stated:
On 14/01/15 16:28, Roberto Ierusalimschy wrote:
So, if the first return is nil, you should be able to safely assume
that there won't be anything of interest after that. Except an
explanation.
You got my point, except about your "except" :-) If the first return is
nil, you should be able to safely assume that there won't be anything of
interest after that. Period.
-- Roberto
Now, how do you imagine these functions:
1. a consumer that is not guaranteed to have data available, like a
nonblocking socket. Today it is
data, err = read()
If data is nil that means that read() could not actually read anything,
so can not provide a value. Depending on how read() works, an error
message could be useful or not. In the simplest case no error message is
needed: no data means no data, do whatever you can.
But the error message can give you more context about the error. For
instance, you could get (I'm using the errno value, but each one has a
unique string):
EINTR the system call was interrupted; depending upon the context,
this could indicate a timeout (if you called alarm() to
prevent a read from taking too long) or some other signal
happened and the operation should be tried again.
EAGAIN The socket is non-blocking, and the read would block. Again,
what you do is contextual.
ECONNRESET
The peer closed its side of the socket.
ENOBUFS
ENOMEM
Not enough memory exists to handle the read.
ETIMEDOUT
The operation timed out.
These errors give you options on how to handle the case where read()
returned nil.
So, I can't remember---are you aguing against nil, or against multiple
returns?
-spc (who likes Lua can return multiple items from a function)
