 |
lua-l archive |
|
|
||
|
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