Error

In Domain Modeling Made Functional, Scott Wlaschin categorizes errors into three groups:

• Domain Errors. These are errors that are to be expected as part of the business process and therefore must be included in the design of the domain, such as an order that is rejected by billing or an order that contains an invalid product code. The business will already have procedures in place to deal with this kind of thing, and the code will need to reflect these processes.

• Panics. These are errors that leave the system in an unknown state, such as unhandleable system errors (such as “out of memory”) or errors caused by programmer oversight (for example, “divide by zero” or “null reference”).

• Infrastructure Errors. These are errors that are to be expected as part of the architecture but are not part of any business process and are not included in the domain, such as a network timeout or an authentication failure.

—pp. 192–3

Different kinds of errors need to be handled differently. This taxonomy helps clarify how to handle any given error.

• Domain errors should be represented using algebraic types (e.g. ResultType or EitherType) returned from domain-specific functions.
• Panics should be ruled out by the type system wherever possible. If they occur, they should simply crash the Process, because there's no way to safely recover from an error you didn't anticipate.
• Infrastructure errors should be represented by algebraic types. Since these errors occur at the edges of the system, handling them explicitly shouldn't be too great a burden.