(non)nullable types

Nick Sabalausky a at a.a
Sat Feb 14 18:42:46 PST 2009


"Christopher Wright" <dhasenan at gmail.com> wrote in message 
news:gn7jn9$1i0e$1 at digitalmars.com...
>
> class Foo {
>     void delegate()? dg;
>     void doStuff() {
>         if (dg) {
>             doPart1;
>             doPart2;
>         } else {
>             // some other long code path
>         }
>     }
>
>     private void doPart1() {
>         // use dg; why should I check?

Because some other function or codepath could still accidentally be breaking 
your precondition convention, so you're right back to inviting hidden. The 
extra check prevents that. Also, in many cases (though not all), doPart1() 
might be better off being generalized like this:

private void doPart1(ref void delegate() dg) {
    // Do stuff
}

...or like this:

private (void delegate()) doPart1(void delegate() dg) {
    // Do stuff
    return dg;
}


>     }
>     private void doPart2() {
>         // use dg; why should I check?
>     }
> }
>
> Small examples don't show it very well.

> Denis Koroskin wrote:
>> private void doPart1()
>> {
>>    void delegate() dg = unchecked(this.dg); // no checking done
>>    // use dg here without checking
>>    // *BUT* it someone denies the contract and calls the method without
>>    // ensuring that this.dg is not null, you'll get a access violation 
>> (or NPE)
>> }
>
> Fuck no.

Agreed. Although my argument against it is that if you're going to bother to 
do that, you may as well just check for null anyway and save yourself the 
potential runtime error. 





More information about the Digitalmars-d mailing list