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

On Fri, Sep 19, 2014 at 12:12 PM, Hisham <h@hisham.hm> wrote:

On 19 September 2014 13:18, Jorge <xxopxe@gmail.com> wrote:
> On 09/18/2014 01:18 AM, Andrew Starks wrote:
>>
>> I've been thinking more about this topic.
>>
>> So, the above quote from the illustrious Dirk seems to be "what smart
>> people do." That is, there is a consensus around this view.
>>
>> I don't think I understand it and I'm starting to think that "nil,
>> error_msg" has no place in my code.
>>
>> The problem with `nil, error` is that "reasonably expect" is both
>> unknowable and possibly irrelevant:
>
>
>
> In my mind, having a library crash the users program emitting an error() is
> not well behaved. As a library you don't know how important is whatever you
> are doing for the host program. Perhaps it doesn't particularly care if
> you're unable do do you task.
>
> So, who has to agressivelly pcall is the library.
>
> Also, as a final user, I find "nil,error" apis much easier to use.

Agreed. When I get a third-party library to integrate with my code
(say, I need to support the FOO protocol and I found a lua-foo module
in LuaRocks that already implements it), I don't expect it to _ever_
force me to pcall.

Just like the policy Rena mentioned, I heartily accept that it may
error() if I'm using lua-foo wrong. But not if it's a call that, for
some reason, may fail. For example, if you're implementing a file-like
interface with an :open() method, then failing to open (something that
may happen because of the user's environment and which I must check in
my code) should return `nil, errmsg` and not crash with error(). On
the other hand, if it takes either "r" or "w" as a second argument, I
expect it to error() if I give it "z".

-- Hisham

Hisham / Jorge:

How do you deal with the following:

1: You parse the input that you receive and you know it to be well-formed.

2: You call a library function that will look for a resource by that name and, if it fails, returns `nil, error`.

3: That same call may also generate an error. For example, perhaps the object contains a dependent resource that is in an invalid state.

I can guess at what the answer to this question is: "if you return nil, error_msg, always return nil, error_msg" So, then the onus is on me to call pcall if there is any risk that an error would result.

Is that correct?

-Andrew

BTW: I think that I may be speaking more towards how I do things internally. My api is restful and so I return an actual error message, not even 'nil, error_msg' to my user.