A happy path is defined as the control flow followed by a program to handle the backbone of an application.
The assumption is that there is only one backbone for an application, and other paths are exceptions, by definition.
The assumption is that the Happy Path is a first-class construct, while the rest of the paths are second-class constructs.
I disagree with the above assumption.
I believe that a program must handle all paths through an application and that all paths are first-class constructs.
With the rise of distributed programming[^distributed], it is important to consider all paths.
[^distributed:] For example, blockchain, p2p, internet, and HTML.
I think that Dave Ackley’s[^ackley] MFM and Robust Computing work also denies the existence of only a single path, although he may describe the problem differently.
I believe that most PLs (Programming Languages) emphasize the single-path perspective and relegate all other paths to a lesser status[^secondclass].
I believe that notation influences thinking, and, therefore, we must begin using PLs that treat all programming paths as first-class constructs.
The Wikipedia entry for “Happy Path” perpetuates this unfortunate perspective:
“… is a default scenario featuring no exceptional or error conditions. …”
PLs Focus on The Happy Path
Every Other Path Must Be Sad
Abdication of Error Handling
Functional Programming Model
Functions are one-in-one-out constructs, everything else is an exception.
Railway Oriented Programming
Diagrams allow expression of multiple outcomes while retaining the essence of mathematical manipulation (aka copy/paste).