The solution to "Error handling"...

[H. S. Teoh]

On Fri, Jul 03, 2026 at 11:08:26PM +0000, Dennis via Digitalmars-d wrote:
[...]
> In [The Easiest Way To Handle Errors Is To Not Have
> Them](https://www.dgtlgrove.com/p/the-easiest-way-to-handle-errors),
> Ryan Fleury gives concrete C examples, but the principles apply to
> other languages as well. I haven't read Walter's book recommendation
> "A Philosophy of Software Design" yet, and if you haven't either,
> maybe that post is more accessible.

That post is insightful indeed.

Only, it begs the question: if zero initialization is so good, why don't
we generalize it to structs with pointers too?  The problem with null
pointers is that we've been conditioned to treat it as a special value,
a bad memory access, such that even the modern OS is designed to trigger
an OS-level exception (i.e. a SEGV signal) when a process tries to read
from address 0.

But does it have to be this way?

What if address 0 is a VALID address to read from, and always guaranteed
to be zero?  Make the first page (4K or however big you want it to be)
of the program's address space point to a read-only zero page.  The
program is designed such that all types are zero-initialized.  So, a
pointer to address 0 is a pointer to the .init value of any type.  So a
null pointer always points to a valid zero-initialized instance of any
type.  Bingo! No more segfaults.  No more special initialization of
pointers.  No need to allocate special memory to hold nil values of each
type - page 0 of your address space *is* the nil value of your types.
Most initialization code can be elided.

Maybe I should start a new programming language on this basis: zero
initialization is the only initialization, and all code must be written
to expect zero as a valid empty value.

//

As far as D is concerned, defaulting floats to NaN breaks the pattern of
zero-initialization, which sucks.  We should default to 0.0 instead!


T

-- 
May you live all the days of your life. -- Jonathan Swift