lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 14/01/15 18:07, Sean Conner wrote:
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
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.

		The peer closed its side of the socket.

		Not enough memory exists to handle the read.

		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

   -spc (who likes Lua can return multiple items from a function)

Errrrr, I don't know what /you/ are arguing about... That was an example of a function that could be unable to return a value under normal conditions, where returning nil is reasonable. As I stated, it could provide an error message if deemed neccesary, or not it it wasn't. I was asking Roberto how was he envisioning this use case under the false-errormessage pattern he mentioned. (read() returning false instead of nil would preclude read() from reading booleans)