A Philosophy of Software Design

[Walter Bright]

On 5/24/2026 8:36 AM, Paul Backus wrote:
> 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.

The idea is to reduce complexity by not having separate error paths entwined 
through the code in visible and invisible ways.

For example, printf has to deal with errors in stdout. That adds significant 
complexity to printf, with or without exceptions.

I do understand that what I am writing here is unconventional and hence 
obviously wrong. I don't expect to convince anyone easily, just like I am unable 
to convince people that macros are a terrible misfeature :-/