The “let it crash” error handling strategy of Erlang, by Joe Armstrong
Tags: erlang
Published: 2023-11-26 13:40:20

This post was motivated by this tweet:
{% twitter 1728756118623605218 %}

_Buy_ [Luciano Ramalho's Fluent Python: Clear, Concise, and Effective Programming 2nd Edition](https://www.amazon.com/Fluent-Python-Concise-Effective-Programming/dp/1492056359).

Click [here](https://erlang.org/pipermail/erlang-questions/2003-March/007870.html) to read the following text by the late [Joe Armstrong](https://en.wikipedia.org/wiki/Joe_Armstrong_(programmer)) in its original context.

In 5 Mar 2003, Luke Gorrie wrote:

... cut ...

> Hope that clears things up for someone else who learned the other
> definition than the Erlang guys :-)

Yes :-)

I have two "thumb rules"

Check inputs where they are "untrusted" 

- at a human interface
- a foreign language program

Or when you want a better error diagnostic than the default one - in this case just exit with the better diagnostic.

For example if I'm parsing an integer I'd write

```erlang
I = list_to_integer(L)
```

or
```erlang
	case (catch list_to_integer(L)) of
	    {'EXIT', _} ->
		exit(["Most honored user I regrettably have to inform you
		      that your input on line", Ln, "was not an integer
		      in fact it was ",L, "which IMHO is wrong
		      have a nice day 
		      Mr. C. Computer"]);
	    I -> I
	end.
```

The latter is "an industrial quality" error message :-)

Note (important) the semantics of both are to raise an exception in the
event of an error. 
	
Aside: I once saw code like this:

```erlang
x(a) -> 1;
x(b) -> 2;
x(X) ->	
    %% what do I do now
    io:format("expecting a or b").
```

The programmer had actually added a comment (What do I do now) - of course they had done the wrong thing.

The program:

```erlang
x(a) -> 1;
x(b) -> 2.
```
Is correct.

Evaluating `x(c)` generates an exception as required.

In their modified program `x(c)` evaluates to the atom `ok` (i.e. the return
value of `io:format`) - which is incorrect.

If they had wanted a better diagnostic they should have written:

```erlang
x(a) -> 1;
x(b) -> 2;
x(X) ->	exit({x,expects,argument,'a or b'}).
```

If you do *nothing* to your code you get a good diagnostic anyway:

If `x` is in the module `m` and you call this in the shell
you'd get:

```erlang
(catch m:x(c)).
{'EXIT',{function_clause,[{m,x,[c]},
                          {erl_eval,expr,3},
                          {erl_eval,exprs,4},
                          {shell,eval_loop,2}]}}
```

`function_clause` means you couldn't match a function head.

```erlang
[{m,x,[c]}, ...
```

means you were calling function `x` with argument `c`.

So in this case NOT programming the error case  results in

1. shorter code
2. clearer code
3. no chance of accidentally violating the spec by introducing ad hoc "out of spec" code to correct the  error
4. perfectly acceptable error diagnostic

IMHO (3) is a  big gain -  specifications always  say what to  do if everything works  - but never what  to do if the  input conditions are not met - the usual answer is something sensible - but what you're the programmer.

In C etc. you  have to write _something_ if you detect an error. In Erlang it's  easy - don't  even bother to write  code that checks for errors - "just let it crash".

Then  write a  _independent_ process  that observes  the  crashes (a linked process) -  the independent process should try  to correct the error, if it can't correct  the error it should crash (same principle)
- each monitor  should try a  simpler error recovery strategy  - until finally the  error is  fixed (this is  the principle behind  the error recovery tree behaviour).

Why was error handling designed like this?

Easy - to make fault-tolerant  systems you need TWO processors.  You can never ever make a fault tolerant system using just one processor - because if that processor crashes you are scomblonked.

One  physical processor does  the job  - another  separated physical processor  watches  the first  processor,  fixes  errors  if the  first processor  crashes - this  is the  simplest possible  way of  making a fault-tolerant system.

This principle is mirrored exactly in the Erlang process structure - this is because we want to have "location transparency" of processes - in other  words at a  certain level of  abstraction we do not  wish to know which physical processor an individual Erlang process runs on.

This is  the fundamental reason  why we use "remote  error recovery" (i.e. handling  the error  in a different  process, to the  process in which  the error occurred)  - it  turns out  that this  has beneficial implications for  the design  of a system;  mainly because there  is a clean separation  between doing a job,  observing if the  job was done
and fixing an error if an error has occurred.

This   organization  corresponds   nicely  to   a   idealized  human organization of  bosses and workers -  bosses say what is  to be done, workers do stuff.  Bosses do quality control and check that things get done, if not they fire people,  re-organize and tell other people to do the stuff.  If  they fail (the bosses) they get  sacked etc.  

Note: I said, idealized organization, usually  if projects fail the bosses get promoted and given more workers for their next project.

Joe Armstrong