FAQ terminology harmonisation

[Matthias Lang]

Rick Pettit writes:
 > On Thu, Apr 03, 2003 at 09:18:46PM +0200, Matthias Lang wrote:
 > > not checking for "NULL" isn't quite the same as the usual erlang
 > > approach. The usual erlang approach is to use pattern matching to
 > > force an abort in many cases where something unexpected happens, e.g.
 > > 
 > >    {ok, S} = gen_tcp:connect(Host, Port, Options),
 > >    ...
 > > 
 > > you can't really write that naturally in C, I find myself forever
 > > writing
 > > 
 > >    sock = connect(...);
 > >    assert(sock);
 > > 
 > > Is that defensive programming? Not really, IMO. PERL has an idiom
 > > which is somewhat like Erlang, btw: f() || die

 > Not sure I completely agree here. Checking for NULL _IS_ checking for the
 > unexpected (you just do it more often in C/C++).  In both cases you
 > expect the connection to be established, and in both examples you 
 > assert that it is.

I do not think the explanation of how to approach error handling in
the programming recommendations is a good one*. Neither do I think
"defensive programming" is a good term for it. I ripped off Joe's
improved explanation in the FAQ (question 10.15)

  http://www.erlang.org/faq/

The key is separating error detection and error handling. The talk
about "defensive" is a distraction. (Aside: I can't find a good
definition of the term. The first 10 links googles gives me all lead
to useless essays calling everything from descriptive variable names
to exceptions "defensive programming". Is it one of those things
everyone feels is a good idea and nobody knows exactly what it is?)

There are two problems with the above style in C. One is that it makes
the code longer. The other is that error handling becomes all or
nothing. If the socket does not connect, the entire program will
die, unless the program is structured into several unix processes. 
Some long-running C programs could actually work reasonably well
with such a model, one example is a web server which fork()s for each
new connection.

In Erlang, there are two main ways to handle errors
non-locally. Exceptions and supervision. I think of the difference as
being a matter of where you draw your boundary. Exceptions draw the
boundary through a certain level of the stack. Supervision draws it
around a process. I use both approaches in our systems, they're
useful in different situations. But the situations where supervision
is useful seem to outnumber the situations where exceptions are useful
20 to 1.

Matt

 * Why did an april fools post contain real criticism? I figured the
   hoax would work best if started plausibly and then ramped up the
   implausibility.