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