incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <>
Subject Re: Design Fundamentals - Null References
Date Wed, 04 Mar 2009 13:05:05 GMT
My reasoning behind wanting to remove nulls is that quite simply   missing ,
incomplete or incorrect data is actually a very common occurrence in a
dump.  We also know that there are various dump types and that the API will
have to deal with optional data.     This combination means that programmers
using the API will unknowing make assumptions about what data is always
present and welformed based on what they have to hand.    We need to ensure
that when that program is run against a new dump it won't break.

Its also true that even the RI developers are going to make the same
mistakes -  I fixed a bug yesterday in some code that made assumptions about
data always being present.   the gist was  something like
getFoo().getName()   where getFoo() almost always returned an object - in
this case it didn't and we got an NPE instead.  Not good.     If we mandate
no nulls then code making the wrong assumptions will fail gracefully.

On Wed, Mar 4, 2009 at 5:13 AM, Bobrovsky, Konstantin S <> wrote:

> 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 []
> Sent: Tuesday, March 03, 2009 11:21 PM
> To:
> 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
> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message