incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bobrovsky, Konstantin S" <konstantin.s.bobrov...@intel.com>
Subject RE: Design Fundamentals - Null References
Date Wed, 04 Mar 2009 05:13:46 GMT
As 'null' is logically close to the meaning of 'nothing' I think it is OK to use it for absent/missing
data. But corrupted data should probably throw a checked exception, as this is a (supposedly)
rarer situation requiring user code reaction. But this may well depend on the usage models
- we can select one approach to start with, but later, after 'profiling' the API on concrete
implementations/tool examples, we might want to reconsider.

If we decide to use 'null' instead of exception, the burden this relays on user code can be
reduced via employing what I'd call 'layered interface' approach coupled with the provider
concept. At any interface layer, all queries it defines or inherits are guaranteed to return
non-null value (implementation would throw some InternalError instead of returning a null,
which would mean an internal error indeed).  The lowest layer would contain only most basic
queries, and the higher we go up the hierarchy, the more queries provided. Implementations
of different layers are provided via some factory methods.

I.e. we could have the following interface layers:

public interface BasicHeapIterator {
        void reset();
        HeapRoot getNextRoot();
}

public interface AdvancedHeapIterator extends BasicHeapIterator {
        HeapRoot getNextOldGenerationRoot();
}

And the following provider:

public class HeapIteratorFactory {
        public static BasicHeapIterator getHeapIterator();
}

The user code would check up front what level of the interface it can obtain:

BasicHeapIterator i = HeapIteratorFactory.getHeapIterator();

if (i instanceof AdvancedHeapIterator) {
        AdvancedHeapIterator ai = (AdvancedHeapIterator)i;
        // use advanced features
} else {
        // use basic features
}
(Alternatively, the above could be made more similar to the MS Component Object Model style)

However, with this style implementation would have to guess for a particular dump which interface
layer can be created for it. This might be not possible in some (many?) cases.

Thanks,
Konst

Closed Joint Stock Company Intel A/O
Registered legal address: Krylatsky Hills Business Park,
17 Krylatskaya Str., Bldg 4, Moscow 121614,
Russian Federation


-----Original Message-----
From: Steve Poole [mailto:spoole167@googlemail.com]
Sent: Tuesday, March 03, 2009 11:21 PM
To: kato-spec@incubator.apache.org
Subject: Design Fundamentals - Null References

This is a continuation of the general discussion about Null references.

I started the discussion with  a link to this
http://developers.slashdot.org/article.pl?sid=09/03/03/1459209&from=rss

My thought for discussion was "should we allow the API to return null  at
any point"  and Adam pointed out that we sort of have to look at exceptions
in the same light too.
If we do apply the same logic then I think that means  no unchecked
exceptions.



Steve

Mime
View raw message