cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
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:14:49 GMT


Joerg Heinicke wrote:

> On 21.04.2004 15:34, Ugo Cei wrote:
> 
>> Marc Portier wrote:
>>
> 
> NPE is really bad - not only here - for the two mentioned reasons. But 
> if you insist on your NPE you can change Ugo's proposal to
> 
> if (id == null) {
>   throw new NPE("id must not be null");
> }
> 
> So we have NPE, which is RuntimeE, meaningful message and early failure :)
> 

Sorry guys, be honest: you can't expect every deref in Java to be 
proceeded by this kind of test?


I admit NPE's are bad, but they indicate programming errors
this one will surely come up during development test (believe me: 
getId() is not something that will happen only in rare cases, I think 
every sweap through any widget lifecycle is bound to call it at least 
twice IMO)


by the way: we should be discussing this in the light of getDefinition() 
not in the light of getId():
it will not even be used for .equals() IIRC, reconsidering this I think 
the returned string will only be used as an argument to 
addCDATAAttribute, hm never tried that, does that yield an NPE?

-marc=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Mime
View raw message