A Philosophy of Software Design

[Jon Degenhardt]

On Sunday, 24 May 2026 at 01:42:43 UTC, Walter Bright wrote:
> The first sentence of the chapter "Define Errors Out Of 
> Existence" says:
>
> "Exception handling is one of the worst sources of complexity 
> in software systems."
>
> I suspect that adding EH to D was a mistake. It certainly was a 
> mistake to build it into Unicode string handling. I'd like to 
> see if we can figure a way to do Phobos without exception 
> handling.

A old paper relevant to error handling is [END-TO-END ARGUMENTS 
IN SYSTEM DESIGN by J.H. Saltzer, D.P. Reed, D.D. 
Clark](https://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf). It uses OS/network level examples, but it applies much more broadly.

The paper argues that proper error handling behavior is only 
known at the application layer, not in low level modules. It 
points out the challenge with implementing error handling only at 
the application layer as being one of efficiency. However, it's 
easy to extend these challenges to those involving error handling 
at the programming language layer. If only the application knows 
how to handle errors, what options do reusable library routines 
have for supporting application needs? It's non-trivial.

Consider reading unicode line by line from an input source. At 
the application level, there are several strategies (that I am 
aware of) an application might want to use when encountering 
invalid unicode bytes in the input.

1. Replace - Replace the invalid byte sequence with a Unicode 
replacement character (U+FFFD)
1. Remove - Like Replace, but don't include the replacement 
character.
1. Passthrough - Leave the offending bytes in place. Only applies 
when the input line is type valid for raw bytes. That is, it's 
not applicable if reading to a string type requiring or assuming 
valid unicode characters.
1. Drop the line - Since this application reading line-by-line. 
Note that in this case the application may also want to signal or 
record that individual lines have been dropped.
1. Stop the program - And take some action, like informing a user.

One challenge is that the application level program may be many 
layers of code away from the line reader. Designing a low level, 
general purpose library that supports a fair variety of error 
handling scenarios is difficult. The exception support or not 
question plays into this, as exceptions are one way to support 
several of these application scenarios.

Unicode error handling is worth attention because of all the 
trouble it's been for D. But it comes up in other places as well.

--Jon