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

[Garrett Smith]

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.

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.

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.