[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: data, err = f() idiom
- From: Jorge <xxopxe@...>
- Date: Thu, 19 Jan 2012 11:47:48 -0200
On jue, 2012-01-19 at 14:25 +0100, Jerome Vuarand wrote:
> 2012/1/19 Jorge <xxopxe@gmail.com>:
> > When writing:
> >
> > local data, err = f()
> >
> > what is the error condition, data being nil, or err being not nil?
> The idiom is to be used with assert, like that:
>
> local data,status = assert(f())
Ok, of course, that answers the question.
> The second is the tcp{client}:receive function from LuaSocket, which
> uses the idiom. It returns nil as the first return value when trying
> to read past the end of stream, followed by "closed", followed by the
> partial result.
This is actually my case: i'm consuming data from LuaSocket, and
generating events on data arrival [1]. So i was thinking the best way of
expressing the "last partial read" case.
Al in all I see 3 options:
1) two signals, one (incompletedata,nil) followed by a (nil, 'closed').
Tough this forces you to check the length of the return always just in
case it is the last read.
2) Drop the last partial read. If you asked for N bytes, that's what you
should get. But why hide the partial data from the user when there's an
unobtrusive way to provide it, as in...
3) Just do what LuaSocket does.
I hate when this happens.
Thanks for the answers!
Jorge
[1] https://github.com/xopxe/Lumen/blob/master/socketeer.lua