Re: error() or nil, 'error msg'

[Jorge <xxopxe@...>]

On 09/21/2014 12:10 PM, Andrew Starks wrote:
> Because most times, there is nothing that you can do. In the last
> example if there were no "EAGAIN", then there would have been no "pcall"
> and no "if then". Even if there is something for you to do, it's only in
> one spot that you do it and it's not uncommon for that spot to be
> further up the stack. If you "nil, err", you have to "if then" back to
> the caller that cares.

Yes, I was meaning more from the aesthetic point of view: suddenly I 
must _always_ put _the same_ code around each call to the library. That 
does look weird (boilerplateish) to me.


> > Likewise, you must do this every time that you might get "nil,
> err" because if you forget, then you have a potentially tricky bug to
> find. With pcall, if you forget, you have an angry user or developer and
> an extremely easy to spot fix for it. [1]

If you want "angry users" for holes in the business logic just assert 
the returns. With ret,err it's the library user decides how much he 
cares/trusts it.

Perhaps the difference can be described as follows:

With ret,err :

* The library doesn't error. If it errors it's a bug.
* The library is not always capable of returning data, for business 
logic reasons. When unable, it explains why.


With pcall :

* a library might error when
  * there was a bug somewhere ("real error")
  * it was unable to return data for business logic reasons.

I still find the first more... I dont' know, nice :)

Jorge