A Philosophy of Software Design

[H. S. Teoh]

On Sat, Jun 27, 2026 at 09:05:34PM -0700, Walter Bright via Digitalmars-d wrote:
> 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 thought that's what unittest blocks were for? ;)


> > 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.

Sure it does.  The stacktrace in e tells you exactly which one failed.


[...]
> > 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.

That does not solve the problem of locating the point of failure.  You
check at the end of the program whether stdout is in an error state, and
it says yes.  Now what?  When did it get into that state?  It's
anybody's guess.

Whereas if File.open() had thrown an Exception, it would have carried
file + line number information with it and you'd know immediately where
the failure happened.


T

-- 
Why did the bear dissolve in water?  Because it was a polar bear.