FAQ terminology harmonisation

[Ulf Wiger]

On Wed, 2 Apr 2003, Rick Pettit wrote:


>Put another way, most all my objects ARE defensive, and
>might as well be placed "on the border". Since this is
>true, I can reuse an internal object on the border without
>worrying about crashes. I can make calls to it from
>anywhere and know that it is well behaved.
>
>The same is NOT true with an Erlang module that is coded to
>crash on bad data since it is not meant for border use. It
>would be a big mistake to use such a module in a border
>case, and thus it is important as an Erlang/OTP developer
>to make crystal clear the distinction.

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.

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.

Thus, the main difference between a component at the
external border and an internal component is not primarily
that one is safe and the other is not, but that one produces
an error message intended for mere mortals, while the other
fails in a way that gives the programmer as much useful
debugging info as possible.

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, ...).

I reuse code quite a lot, and I think most Erlang
programmers do (I know one who doesn't believe in reusing
code, since it's so easy to write working erlang programs
from scratch...)


>Of course the code is much smaller when it is not
>defensively coded throughout the application, no argument
>there. But when both sides (i.e. C/C++ and Erlang OTP) are
>coded that way, what is the difference?
>
>I suppose defensively coding EVERYTHING is a bit silly and
>unnecessary, but this is not a strengh/weakness of
>Erlang/OTP, merely a coding practice that can be (or not
>be) applied to any language.

I recently dusted off the book "Writing solid code" by Steve
Maguire, and browsed through it. Very good book, but it
struck me that among the countless good advice on how to
write robust C code, the most of it was not relevant to
Erlang programmers. The book contains lots of sage advice
that's surely relevant regardless of language, but as good
as the book is, it's hardly worth it to plow through 200
pages of C-specific coding advice in order to get to those
pearls.


/Uffe
-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson AB, Connectivity and Control Nodes