cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Heinicke <joerg.heini...@gmx.de>
Subject Re: [cforms] refactoring questions (was Re: cvs commit: cocoon-2.1/src/blocks/forms/java/org/apache/cocoon/forms/formmodel Struct.java Messages.java Repeater.java MultiValueField.java AbstractContainerWidget.java Output.java Upload.java Action.java Form.java ContainerDelegate.java AbstractWidget.java Field.java Union.java BooleanField.java Widget.java)
Date Wed, 21 Apr 2004 18:12:46 GMT
On 21.04.2004 20:03, Marc Portier wrote:

>>> yeah, but this is something that never needs to be catched it really 
>>> is a programming error, so I find the test for null unesessary and 
>>> the possible resulting NPE as more then RTE enough to commincate the 
>>> coding error.
>>
>> The problem with the NPE is that you'd need to look at the stacktrace 
>> to find what the exception is about, as you get no meaningful message, 
>> and the exception might be thrown when you try to dereference the null 
>> pointer, which could be far from where getId() is called. What I 
>> propose is to throw a RTE when the widget is built. Fail early, if you 
>> can.
> 
> yep that is the idea completely
> id should become a final member of the definition
> as such it needs to be provided during build
> 
> it could still be set to null, but would result in a state 'abstract' of 
> the definition meaning it is an a state that will make the 
> createInstance() on it to throw a RTE (IllegalState IMO)
> (see wiki page WoodyRefactoring)
> 
> this will result in instances that can only point back to definitions 
> that have an id set != null
> 
> so getId() on instance level will effectively lead to always returning a 
> non-null
> 
> unless we have made a programming error in setting up this chain, this 
> is not a circumstance IMO that requires additional RT checking to 
> generate specific RTE's

+1 sounds ok.

Joerg

Mime
View raw message