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