A Philosophy of Software Design

[Walter Bright]

On 5/24/2026 5:47 PM, H. S. Teoh wrote:
> And enforcement doesn't work either: if you force people to handle error
> conditions, they will just do the bare minimum they can to get away with
> it.  Hence the proliferation of C functions that return -1 (or
> equivalent dummy value) for any and every error condition, with no
> indication of what actually went wrong.  Which leads to an entire
> application getting into an error state from some obscure combination of
> conditions, and the only message you can get out of it is "Internal
> error".

You do have a point. However, it's much easier to put a single error check in 
the sink rather than in every single call to printf. (And this his how the sink 
works in dmd.)

Keep in mind that the potential for an exception every single call will insert 
invisible unwinding code, which adds invisible complexity to your code. This is 
addressed in the referenced book.


> On a more serious note, I find D's .writefln a much better debugging
> tool than C's printf.

You're right, but my issue with writefln is even a simple call to it generates 
and absolute blizzard of template code emitted to the object file. Since much of 
my work involves looking at the assembler dump of the code, it becomes hard to 
find what I'm looking for in that blizzard.

I've discussed this with Adam (Phobos2) and he agrees and will address it.