Failures as part of the design.
WHAT THE MECHANISM IS
Functions declaring they can fail, with callers required to handle it.
WHY THAT MATTERS
Failure is visible in the signature, unlike exceptions elsewhere.
WHAT AN ERROR TYPE IS
Usually an enumeration, with a case for each failure.
WHY AN ENUMERATION
It lets callers respond differently to different failures.
WHAT THE HANDLING OPTIONS ARE
Catching and handling Converting to an optional, discarding the reason Asserting it cannot fail, crashing if it does
WHAT TO AVOID
Discarding the reason routinely Asserting where failure is possible
WHAT TO PROPAGATE
Errors you cannot act on, to a caller who can.
WHAT TO ADD WHEN PROPAGATING
Context, so the eventual handler knows what failed.
WHAT RESULT TYPES PROVIDE
A value representing success or failure, useful where errors cross asynchronous boundaries.
WHAT TO SHOW USERS
A message they can act on, never internal detail.
WHAT TO LOG
Enough to diagnose, without personal data.
WHAT TO NEVER DO
Catch everything and continue silently.
WHY
The program proceeds in an unknown state with the cause invisible.
