[erlang-questions] Improve errors for maps

Richard A. O'Keefe <>
Sun Mar 1 23:54:01 CET 2015

On 28/02/2015, at 6:57 am, Anthony Ramine <> wrote:

> Could we some day start a discussion on the state of error reasons in Erlang/OTP?
> Some things are very clueless like discrepancies between the shell and compiled code ([ X || X <- [1], _ = foo ]), non-obvious discrepancies between some filters (replace _ = foo by just foo in previous example) or even plain useless error reasons like {badrecord,foo}.
> Could that be gradually improved on a large timescale?


When we (ok, I) added exceptions to Quintus Prolog,
we (ok, I) developed a classification of errors.
To put this into more-or-less Erlang terms:
 - Failures : the outside world is not as we
   thought it would be (missing file &c).
   It's not the program but the world needs fixing.
 - Errors : the programmer has clearly stuffed up.
   The program needs fixing.
 - Faults : the programmer asked for something
   potentially reasonable, but the system could
   not do it, either because of a capacity issue
   or because of an error in the system.
   The system needs fixing.
Within this, there was a finer classification, like
 - type errors : an argument has the wrong type
 - domain errors : e.g. division by 0, sqrt(-1),
   tail of an empty list, &c
 - syntax errors
 - existence errors : you tried to operate on some
   'object' using a well formed name but there is
   no such object, e.g., calling a non-existent function
 - permission errors : the thing you tried to operate
   on exists but you aren't allowed to do that
The idea behind the classification was that the programmer
doesn't just need to know "what happened" but "what do I
DO about it?"  One major aim was to make it *predictable*:
if you knew what a built in operation did, you should be
able to predict all the error terms it could report.

This classification was simplified and adopted in the
ISO Prolog standard.  It proved necessary to revise it
a bit, but the basic idea of making the possible errors
predictable from the meaning proved sound.

The next step was a boring slog through all the code
where we (ok I) converted all error reporting to the
new structured exception terms, sometimes rewriting
things to try to report errors earlier or clearer,
and above all to report all errors
as if they had come directly from the procedure the
programmer had called, not from deep in the implementation.
It's one of those things you don't actually _enjoy_ but end
up proud of.  

There's a marked contrast between ISO Prolog and
ANSI Smalltalk.  Prolog's exception handling system is
simpler than Java's; Smalltalk's is vastly more
elaborate.  But the ANSI Smalltalk standard has
practically nothing to say about *which* exceptions
get raised, so there is nothing a *portable* Smalltalk
program can actually *do* with exception handling,
except to catch divide by zero.  Again, while Prolog's
exception handling is simpler than Java's, if you are
using a 3rd party library you have no way of predicting
what exceptions they will raise, whereas in Prolog there
are clear guidelines.

Of course, with the Erlang philosophy of error handling
being "log it and crash", there's not so very much that
you *want* the exception system to do.  Even so, having
*informative* exception terms that follow a "pattern
language" for exception terms so that people writing
error signalling code have guidelines to follow can make
it easier to tell what an exception might mean.

More information about the erlang-questions mailing list