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

[Richard A. O'Keefe]

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 means that the code that detects an error should
be concerned *solely* with the (P) issue: how can callers
or exception handlers or whatever reliably discriminate
*this* error from other errors.  Readability of the error
term is NOT A CONCERN.  When it's time to think about (H)
you do that in a *separate* function, the format_error/1
function.

Quintus Prolog did exactly the same.  Code that raised exceptions
generated terms that were easy for a *program* to decode.  There
was a separate user-pluggable predicate for mapping that to text.
Not the least of the reasons for having a separate predicate was
to support multiple human languages.  You really don't want ANY
English (or Dutch, or Japanese, or Hindi, or ...) natural language
wired into your program, and certainly not *scattered* throughout
it.  You want the mapping from program structures to natural language
text *separated* so that it is easy to translate.