Non-null objects, the Null Object pattern, and T.init
Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>
Fri Jan 17 17:40:43 PST 2014
On Saturday, 18 January 2014 at 01:05:50 UTC, Walter Bright wrote:
> Because I've tracked down the cause of many, many null
> pointers, and I've tracked down the cause of many, many other
> kinds of invalid values in a variable. Null pointers tend to
> get detected much sooner, hence closer to where they were set.
Some null pointers. The ones that were set in the current
call-chain, but not the long-lived ones.
Anyway, pointers are special since they link together subsystems.
Yes, it is better to have a null-value than a pointer to a random
location, so "null" isn't the worst value for a pointer. It is
the best arbitrary wrong value, but there is nothing wrong with
saying "Hey, when we are wrong about User identity, we want to
keep the system running assuming a Guest identity".
However C-like null values conflate a wide array of semantics, I
think you can have near half a dozen types of null values in a
database. In c-like languages null can mean: not-yet-initialized
(used too early), failed-computation (bottom),
entity-shall-not-have-subentity (deliberate lack of),
empty-container (list is empty), service-not-ready (try again),
etc.
So yeah, it would be nice if the language is able to distinguish
between the different semantics of "null" of different pointer
types and convert them into something sensible when "cast" to a
different type.
For some pointer types it might make sense to kill the thread,
for others it would make sense to throw an exception, for others
it might make sense to allocate an empty object, for others it
might make sense to use a dummy/sentinel.
It isn't universally true that the best option is to core dump,
but you could do both. You could fork(), core-dump the fork, and
recover the original.
More information about the Digitalmars-d
mailing list