The solution to "Error handling"...

[Meta]

On Sunday, 5 July 2026 at 20:16:24 UTC, Walter Bright wrote:
> On 7/3/2026 4:08 PM, Dennis wrote:
>> In [The Easiest Way To Handle Errors Is To Not Have 
>> Them](https://www.dgtlgrove.com/p/the-easiest-way-to-handle-errors), Ryan Fleury gives concrete C examples, but the principles apply to other languages as well. I haven't read Walter's book recommendation "A Philosophy of Software Design" yet, and if you haven't either, maybe that post is more accessible.
>
> Fleury makes some very sensible points. Well worth reading!

"...return a pointer to a “nil struct”, rather than a null 
pointer"

"Aside from a number of silly implementation details of errno, 
there are reasonable aspects of its design."

"The fact of the matter is, the larger the number of types, the 
larger the number of required codepaths."

"A helpful lesson for me was in reframing error information 
returned by a codepath as error information in addition to 
whatever the “non-error result” is. This small change eliminates 
needless bifurcation of the code receiving the result—it can 
simply be one codepath which processes both valid results (or 
gracefully no-ops, if the valid results are zero-initialized), 
and any error information."

"...in my view, the fact that there is such a widescale (and 
often passionate) conversation about the “need” for “error 
handling language features” is indicative enough of the 
embarrassing state of software development."

This guy's mindset insane to me. Rather than have his program 
crash when it tries to dereference a null pointer, he wants to 
paper over it and keep going like nothing's wrong. A segfault or 
an assert triggering is the correct behaviour in this case; it's 
indicative that something has gone catastrophically wrong, such 
that execution cannot continue.

What if he wrote a text editing program that uses this 
philosophy? When the user wants to save their work, and fopen 
returns such a "nil struct" instead of a null pointer, it would 
appear to the user that their file was saved to disk, only for it 
to be completely lost once the program exits.

Also, who unironically thinks errno is a good way to handle 
errors in 2023? Some of these C programmers need to accept that 
programming techniques have advanced since the 70s.

That being said, his "valid zero values"  and "fail fast"  points 
are fine, but even when making a good point, he trips over his 
bad ones:

"One of the major exceptions to zero initialization as a rule is 
that it’s sometimes worthwhile to compromise it for the purpose 
of providing nil struct pointers."

I dunno, he reminds me of a guy I used to work with who wrote 
maddeningly buggy code. I'd implement some feature or fix a bug 
in one part of the code, but unit tests for a completely 
different part of the code (which he wrote) would fail in the CI. 
I'd have to spend hours tracing through his code to figure out 
where an assumption he made about the state of the program was 
silently failing, because he refused to handle errors in a 
reasonable way and instead wrote code that just ignored them and 
kept going.