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

[Hisham <h@...>]

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