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

[Garrett Smith]

On Mon, Aug 17, 2015 at 5:54 AM, Loïc Hoguin <essen@REDACTED> wrote:
> 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:
>>> 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.

Yeah, my Mom hates those cryptic Erlang term errors :)

For me as a programmer (though Facebook would never hire me so this is
speculative) I will try to tie the error to it's source like this:

open_user_config(Name) ->
   case open_file(Name) of
     {ok, File} -> File;
     {error, Err} -> error({open_user_config, Name, Err})
  end.

which will manifest as, e.g.:

{'EXIT',{{open_user_config,"/etc/user.config",enoent}, ...}

which is pretty easy to follow IMO.

I imagine this is what you're talking about, the difference being in
the use of atoms vs strings as "user descriptors", or no?