(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