Re: [ANN] Lua 5.3.0 (final) now available

[Sean Conner <sean@...>]

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)