A Philosophy of Software Design

[Richard (Rikki) Andrew Cattermole]

On 24/05/2026 5:02 PM, Richard (Rikki) Andrew Cattermole wrote:
> On 24/05/2026 4:27 PM, Richard (Rikki) Andrew Cattermole wrote:
>> 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
> 
> Code Complete 2nd edition has three chapters about error handling, 
> including one for exceptions and another for asserts.
> 
> This includes a brief discussion on each of: return a neutral value (not 
> a character), error codes, log/error message, kill process. Copyright 
> 2004, Page 194, https://www.amazon.com/Code-Complete-Practical-Handbook- 
> Construction/dp/0735619670
> 
> This is taught at tertiary education for programming. My copy was bought 
> because it was required reading.
> 
> Note that CS courses may not cover this, but programming and software 
> engineering qualifications should.

"If you have the luxury of designing an API, design it in such a way 
that it minimizes the amount of error handling that is required, if at 
all possible. In addition, try to design APIs so that failures are not 
potentially critical if they go unhandled.

Otherwise, appropriate exception handling can help you ensure that no 
errors that go unhandled will propagate dangers error conditions. Use 
wrappers to convert functions that may fail with traditional error code, 
so that they instead use exception handling." - Secure Programming 
Cookbook, Copyright 2003, 
https://www.amazon.com/Secure-Programming-Cookbook-Cryptography-Authentication/dp/0596003943

The more appropriate solution for D, is to use a struct that wraps the 
value:


```d
struct ErrorCode {
	int code;
}
```

Treat this like any result type, with opCast and @mustuse rather than 
using exception handling. Because it doesn't supply a value, you don't 
need the opUnwrapIfTrue in this particular case.

Ideally we could swap 1:1 at the function prototype, but LLVM will error 
if you try to do this, so that is a potential improvement we could have.