[erlang-questions] feedback on my solutions to programming erlang second edition

[Loïc Hoguin]

On 08/17/2015 12:38 PM, Garrett Smith wrote:
> On Mon, Aug 17, 2015 at 3:15 AM, Loïc Hoguin <essen@REDACTED> wrote:
>> On 08/17/2015 02:36 AM, Richard A. O'Keefe wrote:
>>>
>>>
>>> On 14/08/2015, at 11:29 pm, Roelof Wobben <r.wobben@REDACTED> wrote:
>>>>
>>>> So it's fine to give this a error message :
>>>>
>>>> ** exception error: {read_file,"wrong.txt",enoent} in function
>>>> my_file:read/1 (my_file.erl, line 8))
>>>
>>>
>>>> I think a unexperience users still does not know what went wrong.
>>>
>>>
>>> You are 100% right that there is a conflict here between
>>>
>>> (P) reporting an error in a way that
>>>       a PROGRAM can readily catch and handle
>>> (H) reporting an error in a way that
>>>       a HUMAN can readily understand.
>>>
>>> You are not the first to run into this,
>>> and there is a pattern for dealing with it in Erlang:
>>>
>>>      if a module M reports error E
>>>      call M:format_error(E) to get a human-readable text.
>>>
>>> See http://www.erlang.org/doc/man/file.html#format_error-1
>>> for an example.
>>
>>
>> This is the pattern that is in Erlang but honestly it is very limited.
>>
>> Take the HTTP protocol for example. There are a thousand ways things can go
>> wrong. Are you really going to make a separate atom for each error and then
>> call format_error to know what went wrong? How do you call them,
>> parse_error0, parse_error1, parse_error2? Are you going to end with
>> parse_error formatted as "Parse error." without any clue of what actually
>> went wrong?
>>
>> I find that returning {error, ErrorForPrograms, ErrorForHumans} is a much
>> saner solution because the first error value helps the program know what
>> kind of error it is, and the second error value says exactly what happened
>> for the human who is debugging (locally or when calling an HTTP service, as
>> this error can also be sent as response).
>>
>> This has the additional benefit that the ErrorForHumans value also serves as
>> inlined documentation.
>
> I wouldn't make this as a general recommendation for folks. It might
> make sense in a particular application.
>
> My rule is that an error should convey the minimal amount of
> information to identify and fix a problem. In a lot of cases that's an
> internal problem that needs some rethinking, additional logic, etc.
> but once handled properly shouldn't surface to the user. Problems that
> can legitimately be handled by a user, including some user readable
> content in the original message seems fine. As for i18n, it's common
> to translate the original message, usually in English, when presented
> to the user.

The error message I am talking about is *not* for end users (i.e. your 
mom on Facebook) but for *developers* (i.e. Facebook engineers) who have 
to look at the logs and figure out what went wrong.

> For me the task at hand is to augment an error condition with context
> so you can resolve it. E.g. adding a filename to a file error, which
> by itself is completely useless.

Files are harder, because having the filename will probably not help you 
anyway. Sometimes you do know exactly what the error is about, though, 
so put a nice message with all the related info for the guy who will 
debug this.

> I wonder why stack variables aren't included in stack traces - I've
> never seen that in any language (Richard? :) but it would be
> fantastically useful.

That would be pretty cool.

-- 
Loïc Hoguin
http://ninenines.eu
Author of The Erlanger Playbook,
A book about software development using Erlang