From kato-spec-return-56-apmail-incubator-kato-spec-archive=incubator.apache.org@incubator.apache.org Wed Mar 04 05:14:48 2009 Return-Path: Delivered-To: apmail-incubator-kato-spec-archive@minotaur.apache.org Received: (qmail 87310 invoked from network); 4 Mar 2009 05:14:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Mar 2009 05:14:48 -0000 Received: (qmail 41437 invoked by uid 500); 4 Mar 2009 05:14:48 -0000 Delivered-To: apmail-incubator-kato-spec-archive@incubator.apache.org Received: (qmail 41411 invoked by uid 500); 4 Mar 2009 05:14:47 -0000 Mailing-List: contact kato-spec-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: kato-spec@incubator.apache.org Delivered-To: mailing list kato-spec@incubator.apache.org Received: (qmail 41399 invoked by uid 99); 4 Mar 2009 05:14:47 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 03 Mar 2009 21:14:47 -0800 X-ASF-Spam-Status: No, hits=-4.0 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.55.52.93] (HELO mga11.intel.com) (192.55.52.93) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Mar 2009 05:14:37 +0000 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 03 Mar 2009 21:11:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.38,298,1233561600"; d="scan'208";a="435976214" Received: from unknown (HELO irsmsx602.ger.corp.intel.com) ([163.33.3.242]) by fmsmga002.fm.intel.com with ESMTP; 03 Mar 2009 21:10:01 -0800 Received: from irsmsx504.ger.corp.intel.com ([163.33.3.240]) by irsmsx602.ger.corp.intel.com ([163.33.3.242]) with mapi; Wed, 4 Mar 2009 05:13:48 +0000 From: "Bobrovsky, Konstantin S" To: "kato-spec@incubator.apache.org" Date: Wed, 4 Mar 2009 05:13:46 +0000 Subject: RE: Design Fundamentals - Null References Thread-Topic: Design Fundamentals - Null References Thread-Index: AcmcJJx5RQk2yjR0RmiYIKyaP01wYgAW71DQ Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org As 'null' is logically close to the meaning of 'nothing' I think it is OK t= o use it for absent/missing data. But corrupted data should probably throw = a checked exception, as this is a (supposedly) rarer situation requiring us= er code reaction. But this may well depend on the usage models - we can sel= ect one approach to start with, but later, after 'profiling' the API on con= crete 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' ap= proach coupled with the provider concept. At any interface layer, all queri= es it defines or inherits are guaranteed to return non-null value (implemen= tation would throw some InternalError instead of returning a null, which wo= uld mean an internal error indeed). The lowest layer would contain only mo= st basic queries, and the higher we go up the hierarchy, the more queries p= rovided. 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 obtai= n: BasicHeapIterator i =3D HeapIteratorFactory.getHeapIterator(); if (i instanceof AdvancedHeapIterator) { AdvancedHeapIterator ai =3D (AdvancedHeapIterator)i; // use advanced features } else { // use basic features } (Alternatively, the above could be made more similar to the MS Component Ob= ject Model style) However, with this style implementation would have to guess for a particula= r dump which interface layer can be created for it. This might be not possi= ble 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=3D09/03/03/1459209&from=3Drss 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