A Philosophy of Software Design

[H. S. Teoh]

On Sun, May 24, 2026 at 02:15:47PM -0700, Walter Bright via Digitalmars-d wrote:
[...]
> 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 :-/

You convinced me that macros are a terrible idea. :-D  Actually, you
didn't need to do much convincing.  Having experienced them myself, and
having to work with them every now and then at work (which involves a
(very) large mostly-C/C++ codebase), and also having written a winning
entry for the IOCCC with a fair amount of macro abuse, I've seen what
they're capable of, and also what horrors they can bring.  It didn't
take much to convince me there are better ways of solving problems.

As far as error-handling is concerned, I find exceptions very useful in
my own code, where they help to keep the main logic clear, and separate
out the messy error-handling stuff into a separate place without
cluttering the main algorithm.  IME the more straightforward the main
logic is, the less likely there are bugs.  The more error-handling you
have to insert inline, the more places there are for bugs to hide.
Throwing an exception to abort a complex calculation is better than
sprinkling tons of `if (value.isNaN)` all over your code, or whatever
its equivalent is (error node, null value, etc).

But if you're finding yourself having to write tons of catch blocks
everywhere, then you're doing something wrong. Then it's no better than
sprinkling `if (x is null)` or `if (x.isNaN)` everywhere.  In general, I
find that exceptions should mostly be used only to signal conditions
worthy of aborting an operation entirely, cases where you basically
print a message to the console and abort the process or similar.  Less
extreme conditions often don't deserve an exception.  I'd even go so far
as to say that if your catch block is more than just logging an error
message and signalling failure (abort program, abort current operation,
etc.), you're doing something wrong.


T

-- 
Sometimes the best solution to morale problems is just to fire all of the unhappy people. -- despair.com