View source for Erlang (programming language)/Tutorials/otp design

===Fail early and often===

Fail early and often is a strange and unusual programming method used in OTP.
Processes are programed to a specification about how to handle good input. If 
bad input is seen by a worker process we let the process crash. 
The supervisor restarts the worker process. The effect is that the bad input is ignored.
By only programming to good inputs the program is kept short aiding
readability and maintainability.  

Fail early and often should work well with any type of data flow situation
when a program is processing a flow of messages.
Logically, security and stability is increased by limiting 
the propagation of errors to other processes from
the location of the error.

===Debugging OTP===

Messages are fairly easy to track. By watching messages 
move between process, debugging can be simplified as compared with
tracing low level state changes, which do not 
happen in processes written in a functional language.
The only state changes that happen are in databases 
if we use strict functional methods.

===Isolate the pure from the impure===

Write as much of the program as possible as a strictly 
functional program. Isolate the non-functional activities
from the functional activities. This keeps the parts of 
the program with pesky state-changes as small as possible.

Note: The gray zone

Other exceptions to strict functional programming include
the use of random number generators, and the sending and receiving
of messages. These two exceptions are not so difficult 
to handle and are technically impure
but often unavoidable and hence allowed in 'pure' code.