Happy Path

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.

[^ackley:] https://www.cs.unm.edu/~ackley/

I believe that most PLs (Programming Languages) emphasize the single-path perspective and relegate all other paths to a lesser status[^secondclass].

[^secondclass:] For example, JavaScript callbacks, and thread libraries.

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. …”

[^wiki:] https://en.wikipedia.org/wiki/Happy_path

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).

See Also

Table of Contents