FAQ terminology harmonisation

[Rick Pettit]

On Thu, Apr 03, 2003 at 11:07:34AM +0200, Ulf Wiger wrote:
> Remember that Erlang was designed for environments where
> "resetting" is probably a more correct description than
> "crashing" -- the program always has to bounce back,
> preferrably without the external users noticing.

Of course. Though C/C++ processes which are started out of inittab (Solaris)
or started via daemontools do "bounce back", it can hardly be argued that the
external user wouldn't notice :-).

> I think the idea of having defensive interfaces wherever
> human (or otherwise external) input is involved is a good
> thing, but internal components should assume that the users
> of the interface have RTFM and use the component properly.
> In any event, misuse of the component should lead to
> distinct failures, not mystical semi-correct behaviour.

Agreed. Out of curiousity, if you were to write a C/C++ application (I know,
it's too gruesome to think about), would you follow the same strategy? That
is, would you NOT check for NULL, etc, in cases where you just should not
be passed NULL? How about in an application comprised of distinct processes in
a chain which could die and be reborn without the entire application crashing?

Of course such a system is far _inferior_ to the OTP equivalent, I am just 
curious. And I think it goes without saying that referencing a NULL pointer
in code that is not defensive will not lead to semi-correct behaviour, but
rather a very distinct failure. Of course referencing a non-NULL pointer
which points at a region of memory the author was not aware of is another
story altogether, so perhaps this whole argument is mute (another win for
Martin's argument with "LM").

> I think it's a mistake to confuse the two, but also always
> try to write my code in the same way in both cases. Error
> handling in the external interface is taken care of by
> catching exceptions at the top and interpreting the
> exception information into a human-readable error message.
> This top layer will have different semantics depending on
> the nature of the interface (window-based GUI, command line,
> HTML pages, ...).

Agreed. Though I think a similar strategy could be taken with C++ and 
exceptions. Of course being completely non-defensive in the core of the 
application could lead to segfaults (though I believe even these exceptions
can be caught, though the process is doomed after the exception handler
returns, IIRC).

-Rick