A Philosophy of Software Design

Meta jared771 at gmail.com
Mon May 25 06:15:20 UTC 2026


On Sunday, 24 May 2026 at 01:39:48 UTC, Walter Bright wrote:
> My compiler took a different approach. It would just keep 
> enlarging the string buffer until it ran out of memory. Then 
> there was only one error message - "out of memory" - and the 
> compiler would abort. This applied to all sorts of arbitrary 
> limits the C spec placed on things. There was no need to add 
> error recovery code.

I dunno, I don't really agree with this point of view. If your 
software isn't doing proper error handling, then I don't think 
you're really writing serious software; you're doing toy hobby 
projects. It'd drive me insane trying to use a compiler that 
randomly dies in the middle of compilation with only an "out of 
memory" message to tell me what went wrong. Imagine if all 
software were written this way - it'd be complete and utter hell.

That exception handling quote from the book seems ridiculous to 
me as well. I worked in cybersecurity for over 10 years on 
multi-million LoC SIEM products, huge multi-team, cloud-based, 
microservice architecture products, enterprise server software... 
exception handling was never a major source of complexity in any 
of them. The three major sources of complexity were:

1. The business logic of the applications.
2. Ensuring the various components were initialized properly, 
atomically, and in the correct order.
3. The enormous tech debt that comes from people doing ugly hacks 
to get something implemented as quickly as possible, which years 
down the line become essentially impossible to remove without 
rewriting huge swathes of code.


More information about the Digitalmars-d mailing list