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

[Loïc Hoguin]

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.

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