The Easiest Way to Handle Errors Is to Not Have Them

> The primary reason reading from pointers (prepared by other codepaths) may cause an access violation is because code preparing the pointers often makes the decision to (a) return a pointer to some valid and accessible spot, or (b) return a null pointer. In the case of (a), the pointer can be read from without an access violation. In the case of (b), it cannot.

> But a simple solution is to prefer option (c) to (b)—return a pointer to a “nil struct”, rather than a null pointer, if (a) fails. This nil struct is allocated up-front and may be stored in read-only memory. Any pointers contained in the nil struct point to other nil structs of the associated type. If there are pointers to the same type, they point at the same nil struct in which they’re contained (in other words, the pointers are self-referential).

With this one:

> “You take great pains to avoid null-valued objects,” said the master. “You initialize all Strings to empty, and coerce nulls to empty when setting String-valued properties. Furthermore you store the properties of your Data Transfer Objects in primitives, causing null integer columns to be read as zeroes and null booleans to be read as false. Explain.”

> The boy replied: “In my experience, our most common production error is the NullPointerException. I seek to minimize the occurences of this.”

Aren't both of those saying exactly the same thing, specifically to use valid but dummy values in place of NULL?