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 strict 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.