Tha Happy Path is the path through code when “everything goes right”.
Software must deal with other paths through code - paths to execute when something fails.
Other paths are even more important in distributed code, e.g. internet.
Connections might fail.
Connections might time out due to other reasons, e.g. taking too long to respond.
Second Class Citizens
Most current PLs make it easy to write code for the happy path.
Most current PLs address code for other paths as second class issues, e.g. by providing syntactical warts, like exceptions.
Thinking and coding only for the happy path is Waterfall Design.
StateCharts address, both, happy paths and other paths in the same way, using the same programming syntax and contstructs.
Functions are a notation that is unbalanced.
With functions, the happy Path is first-class, and other paths are second class.
Functions address only the happy path - input, process, return a value.
Exceptions use a different syntax and follow a different dynamic call chain for the happy path.
Send () does not differentiate between happy path and other paths.
The syntax is the same for happy path and other paths.
The Architect can design code for multiple paths without resorting to syntactic ornaments.
Drakon treats other paths as first class citizens.
The Drakon tutorials are very good introductions to happy+other path notation:
Component Based Programming and consider Drakon to be a subset of CBP (Drakon would be a good way to implement leaf components).
It is difficult to implement other paths using synchronous, non-concurrent, code.
It is easy to implement other paths (and the happy path) in the concurrent paradigm.
Aynchronous code and parallel code are easier to design in the concurrent paradigm.
Most current PLs treat asynchrony as a second class paradigm.
It is straight-forward to simulate concurrency on synchronous operating systems (See
CALL/RETURN Spaghetti) [Note that threading is, also, just a simulation.]
Backtraces are a tell that indicates happy-path-only thinking.
Happy-path-only => Waterfall design.
Tell: Poor Error Messages
Poor error messages are a tell that happy-path-only thinking has been used in the design, e.g. error handling is avoided and relegated to second class status.
Elm claims to have good error messages.
Compiler technologies researched error handling in the 1970’s. (At the least, maybe earlier).
For example, you do not expect a compiler to produce multi-line warnings, multi-line error messages and to stop after the first error.
Early Lisps included experimental constructs for handling warnings and errors, e.g. restarts. (Lisp suffered a dimunition of such abilities when CL was standardized, compilatility was emphasized over other path coding).
FP - Functional Programming
Using FP, one is encouraged to deal with the happy path and to relegate other paths - exceptions and errors - to second class status.
(This is not surprising, since FP is based on functions, see above).