dereferencing null

[Jonathan M Davis]

On Wednesday, March 07, 2012 22:58:44 Chad J wrote:
> On 03/07/2012 10:40 PM, Jonathan M Davis wrote:
> > On Wednesday, March 07, 2012 22:36:50 Chad J wrote:
> >> On 03/07/2012 10:08 PM, Jonathan M Davis wrote:
> >>> On Wednesday, March 07, 2012 20:44:59 Chad J wrote:
> >>>> On 03/07/2012 10:21 AM, Steven Schveighoffer wrote:
> >>>>> You can use sentinels other than null.
> >>>>> 
> >>>>> -Steve
> >>>> 
> >>>> Example?
> >>> 
> >>> Create an instance of the class which is immutable and represents an
> >>> invalid value. You could check whether something is that value with the
> >>> is operator, since there's only one of it. You could even make it a
> >>> derived class and have all of its functions throw a particular exception
> >>> if someone tries to call them.
> >>> 
> >>> - Jonathan M Davis
> >> 
> >> Makes sense.  Awfully labor-intensive though.  Doesn't work well on
> >> 
> >> classes that can't be easily altered.  That is, it violates this:
> >>> - Do not modify the implementation of UnreliableResource.  It's not
> >>> always
> >>> possible.
> >> 
> >> But, maybe it can be turned it into a template and made to work for
> >> arrays too...
> > 
> > Personally, I'd probably just use null. But if you want a sentinel other
> > than null, it's quite feasible.
> > 
> > - Jonathan M Davis
> 
> Wait, so you'd use null and then have the program unconditionally crash
> whenever you (inevitably) mess up sentinel logic?

Yes. Proper testing will find most such problems. And it's not like having a 
non-null sentinel is going to prevent you from having problems. It just means 
that you're not distinguishing between a variable that you forgot to 
initialize and one which you set to the sentinel value. Your program can die 
from a variable being null in either case. And in _both_ cases, it's generally 
unsafe to continue executing your program anyway.

And honestly, in my experience, null pointers are a very rare thing. You catch 
them through solid testing.

- Jonathan M Davis