A Philosophy of Software Design

[Paul Backus]

On Sunday, 24 May 2026 at 04:10:31 UTC, Walter Bright wrote:
> Some examples of defining them out of existence:
>
> 1. The C Standard says the compiler must support n characters 
> in a string literal. Implementing this involves detecting the 
> overflow, issuing an error message, and then recovering. A 
> define-out-of-existence approach, which I've always used, is 
> just keep mallocing memory until the memory allocator fails - 
> and then abort the program with "out of memory". You'll see 
> this in the compiler code.
>
> 2. Instead of throwing an exception when encountering an 
> invalid code point, the unicode handler should substitute in an 
> "invalid character" code point. This behaves much like a 
> floating point NaN value.
>
> 3. Invalid code nodes are replaced with "Error" nodes. This 
> worked far better than I anticipated. No exceptions are thrown. 
> It also behaves like NaN.

This is one way to define exceptions out of existence: expand the 
range of possible output values to include new values that 
represent errors (e.g., NaNs, Error nodes, failure states of 
Result/Option types). This pushes responsibility for handling 
those new values onto downstream code, which now has to include 
checks for isNan, isError, and so on.

The other way is to restrict the range of possible *inputs* to 
the function, so that the specific inputs that would cause an 
exception to be thrown are no longer possible. For example, you 
could have your string-handling function take a ValidatedString 
as its input instead of a plain string, and design the public API 
of ValidatedString to ensure that you can only create one from a 
string whose code points are all valid. This pushes the 
responsibility for handling invalid code points onto upstream 
code.

What these approaches have in common is that neither one actually 
removes the need for error handling. They just change where the 
error is handled.