A Philosophy of Software Design

[Richard (Rikki) Andrew Cattermole]

On 24/05/2026 4:10 PM, Walter Bright wrote:
> Thanks. This is an interesting general purpose method.
> 
> But the book suggests a different approach in the title - define them 
> out of existence. I've also thought of various general replacement 
> schemes for exceptions.
> 
> The difficulty with exceptions is they are complicated. It's difficult 
> to figure out what path the code execution goes through when there are 
> various exceptions. The exception paths are also a rich source of bugs 
> because they are untested and may never trigger.
Where possible yes, you should remove the possibility of needing to 
handle the error case.

But you can't always do this especially for a standard library.

It's far more on the rare side to have a problem where you can do it for 
and there are enough cases even in UTF/Unicode to want it to produce an 
error that you must handle.

An awful lot of application development is based upon the principle of 
log + finalize outputs + kill task. And that requires some method of 
unwinding, either implicitly via EH or explicitly via result types.

It is fairly well known and has been taught in software engineering for 
a long time to avoid unnecessary logic like error handling here.

"Do any of your functions return error values? Is it possible to 
redefine those functions to eliminate the error conditions? Remember 
that when a function returns an error, that error must be handled - or 
mishandled - at every point of call."  Writing Solid Code, Page 198, 
Copyright 1993. 
https://www.amazon.com/Writing-Solid-Code-Microsoft-Programming/dp/1556155514