liveBook · Manning

Failure

As explained in Functional Design and Architecture: Examples in Haskell

An error is a condition in software or its environment indicating that a computation or requested operation cannot produce the intended result.

Failure is a condition in software or its environment where a computation or requested operation cannot produce its intended result. In engineering terms, errors are usually expected or possible erroneous states, while exceptions are language-dependent mechanisms for interrupting control flow when something unexpected occurs. section 13.1.1 section 13.3

Treat failure according to its kind and boundary:

  • Handle errors explicitly as probable states associated with particular circumstances or domains. section 13.1.1
  • Reserve exceptions for unexpected conditions and understand that uncaught exceptions may terminate execution to prevent further corruption or security breaches. section 13.1.1
  • Abstract native errors at domain boundaries so external libraries and language ecosystems do not couple business logic to implementation details. section 13.1.1
  • Divide applications into error domains, giving each domain an appropriate handling strategy and converting representations at its boundaries. section 13.3

One situation, two failure mechanisms

A probable, domain-related erroneous situation is an error and belongs in explicit handling. An unexpected condition caused by a likely bug is exceptional and may interrupt evaluation through an implicit control flow. Languages and practices differ: Haskell supports several exception and error-handling mechanisms, while Rust has no exceptions as a language feature. section 13.1.1 section 13.3

How Functional Design and Architecture: Examples in Haskell covers it

How deep it goes
Distinguishes errors from exceptions and prescribes domain separation with boundary conversion, without specifying one universally preferred implementation.
Examples
Uses Haskell’s exception mechanisms, Rust’s lack of exceptions, native errors, and architectural error-domain boundaries as concrete illustrations.
What it assumes
Assumes familiarity with software applications and architectural layers while distinguishing engineering concerns from domain concerns.
What you can do after
Evaluate/understand whether a failure is an error or exception and place its representation and handling at an appropriate domain boundary.
How it connects
Connects failure with exceptions, native libraries, error domains, dependency inversion, functional programming, Haskell, and Rust.

Also explained in

Compare how 12 books explain failure →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Functional Design and Architecture: Examples in Haskell. The section links point to the parts of the book it draws on.