A Philosophy of Software Design

[Walter Bright]

On 6/27/2026 8:30 PM, H. S. Teoh wrote:
> Whereas with an exception, you immediately know exactly where the point
> of failure is: the exception carries with it file and and line number
> information.

If it's a fatal error, that's ok. But if you need to "fix and continue", then 
exception unwinding has proved to be a problem due to hidden and probably 
untested code paths. It also makes it complicated for the programmer to figure 
out if these hidden paths are correct or not.



> I prefer an exception-based mechanism:
> 
> ```d
> try {
> 	writeln("hello");
> 	writeln("betty");
> 	...
> } catch (Exception e) {
> 	handleIt();
> }
> ```
> 
> Not much different from your 2nd variant, with the advantage that the
> Exception object tells you exactly where the problem happened,

It doesn't tell you which of the two writeln()s failed.


> That's what I was getting at.  So you have code that continues running
> as if the file is not in an error state.  Like floating-point
> calculations that absorb a NaN and continue computation as if nothing
> was wrong, only each time NaN propagates to the result.  You don't know
> until the end that a problem has occurred earlier.  In the case of NaNs,
> it's not so bad because a NaN in the output is an obvious indicator of a
> problem.  With a file in an error state, the program may continue
> running in ignorance of the problem until the end, and if the programmer
> was careless the program might even declare success, only when you look
> at the output file it's empty (because the file object was in an error
> state so all operations were no-ops).  And now you're scratching your
> head as to why the program produced an empty file instead of the
> expected output.

That is indeed the idea, but the trouble comes from the non-trivial complexity 
that results in unknown and untested execution paths.


> I'm not saying that your idea has no merit.  My point is that it
> depends.  For some cases, yes, having a NaN (or equivalent) to poison
> the computations help you simplify your code.  I wouldn't want to have
> to check for an error state after every single floating-point operation,
> for example; that would be unreasonably onerous.  But in other
> situations, like opening an output file, I *do* want to know immediately
> if there's a problem, instead of having the program blindly running all
> the way to the end and perhaps even deciding that output was produced
> successfully, only for the user to discover afterwards that the output
> file is empty or missing.

Yes, it would be poor design for the result to say it was "successful" when it 
is in an error state. A better design would be to ask it at the end if it 
succeeded, and if it did not succeed, provide the cache any diagnostic information.