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

[Andrew Starks <andrew.starks@...>]

On Saturday, September 20, 2014, Jorge <xxopxe@gmail.com> wrote:
> On 09/19/2014 06:52 PM, Andrew Starks wrote:
> > First, I appreciate anyone and everyone that is sticking with me on
> > this. I hope that I do not sound argumentative. The responses thus far
> > are helpful.
>
> Just in case, I must say I find these kind of threads wildly interesting :)
>
> > Your example is essentially how I do everything now. Here is the pcall
> > variant, for comparison:
>
> I think the conceptual difference is that the ret,err scheme assumes you care more for the result, and only then for details on errors, and in the pcall is the other way: you first want to know if there was an error, then take care of the return.
>
> Another con of pcall based APIs is that it looks like boilerplate code: if I am supposed to always do some magic incantation for invoking the library under the risk of crashing everything, then why the library doesn't do it itself for me :)
>
> Jorge

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. 

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]

-Andrew

[1] whenever I rant like this, I think about what I'm missing. I think that it's possible that error issues become trickier when things are IO and thread heavy and when they're not separated correctly. The possibility has me worried for my own code. :)