Structs (was RE: Record selectors)

[Ulf Wiger]

On Wed, 15 Jan 2003, Chris Pressey wrote:

>On Wed, 15 Jan 2003 10:39:07 +0100 (CET)
>Joe Armstrong <joe@REDACTED> wrote:

>>   My view is that data validation *only* occurs at a
>>   human -> computer interface and  at a boundary
>>   where two components communicate  via. a protocol
>>    and where the components are not trusted.
>
>Ah!  I feel very similarly, except my view is that I
>shouldn't fully trust *anything* outside the current module
>- not even my own code, since I'm human and I make
>mistakes.  In other words, every module is a boundary where
>components communicate with a protocol, even if that
>protocol is just a set of exported Erlang functions.


I think there is a difference in programming cultures that
might cause some misunderstanding here.

Good Erlang programs actually do tons of validation on
internal data structures, but implicitly through pattern
matching. The philosophy is rather one of always trying to
write functions that either return a valid response or fail.
This is most similar to assertions.

Some typical examples would be:

  read_config(ConfigFile) ->
     {ok, Term} = file:consult(ConfigFile),
     load_config(Term).

The implicit assumption here is that (a) ConfigFile actually
exists and is readable, and (b) it contains one or more
Erlang terms (in ASCII format), each terminated with '.'
We do not attempt to resolve in our code whether (a) and (b)
in fact hold, but rely on the fact that file:consult/1 will
not return the pattern {ok, Term} otherwise.

An example that I have in fact encountered in real code is:

  {_, Result} = mnesia:transaction(F),

This is horrid and absolutely forbidden, since it will
potentially bind Result to what is effectively garbage (the
error description if the transaction were aborted.)

The fundamental difference to most other programming
environments is, I believe, the rule that "crashing is a
valid, and recommended, way to handle bad data."

This holds for internal data that _should_ be OK. It does
not hold for user input, where you actually have to respond
to the user in a civilised fashion (exploding or returning a
50-line erlang crash report does not qualify as civilised.)

/Uffe
-- 
Ulf Wiger, Senior Specialist,
   / / /   Architecture & Design of Carrier-Class Software
  / / /    Strategic Product & System Management
 / / /     Ericsson Telecom AB, ATM Multiservice Networks