commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [digester] assertion mechanism throws Error [was: plugins module ready for evaluation]
Date Tue, 28 Oct 2003 01:36:12 GMT
Simon Kitching wrote:

>On Tue, 2003-10-28 at 02:53, robert burrell donkin wrote:
>  
>
>>On Sunday, October 5, 2003, at 10:53 PM, Simon Kitching wrote:
>>
>>    
>>
>>>On Sun, 2003-10-05 at 00:43, robert burrell donkin wrote:
>>>      
>>>
>><snip>
>>
>>    
>>
>>>>3. Exception handling
>>>>
>>>>PluginAssertionError extends Error. i'm not very happy about this. IMHO 
>>>>a
>>>>well behaved component should not throw any Error subclasses. i'd be
>>>>happier for PluginAssertionError to be renamed PluginAssertionException
>>>>and extend RuntimeException.
>>>>        
>>>>
>>>Having PluginAssertionError extend Error was a very deliberate choice.
>>>It is modelled after the java 1.4 assertion mechanism, where an
>>>assertion failure generates AssertionError.
>>>
>>>PluginAssertionError is never thrown due to a mistake on the part of the
>>>user of the Plugins module, nor due to a mistake in the xml of any sort.
>>>It is only thrown when a bug in the plugins library is detected.
>>>      
>>>
>>i probably should clarify my opinion: no well behaved component should 
>>throw an Error in production. in many context's the throwing of an Error 
>>in production can be pretty serious. in a J2EE context, a container may 
>>mark a bean or a thread which throws an Error as dead. in a production 
>>environment, this may cause problems with these pooled resources.
>>
>>in a way, though finding a bug in the plugins library in production may 
>>irritate a user a little, i'm pretty sure that they will be very angry if 
>>a bug in the plugins library causes their J2EE application to fail through 
>>resources starvation. so, i'm not too sure what the best way to handle 
>>this situation is but i don't think that throwing an Error is the right 
>>thing to do. maybe, it could be replaced with a runtime.
>>    
>>
>
>I see your point. However it seems to me that what you are arguing is
>that the *official* java assertion mechanism is fatally flawed, and will
>never be acceptable in Apache code. That might be right, but is a pretty
>significant decision.
>
>I just feel that the fellows who designed java assertions are pretty
>smart, and must have had a reason for deciding to define AssertionError
>instead of AssertionException. Rather than assume I'm smarter than them,
>I followed their lead on this issue.
>
>Do you think it is worth opening up this discussion more widely on
>commons-dev? What do the Avalon or Tomcat people think about the
>java 1.4 assertion model?
>
>  
>
As a (basically) former Tomcat person, I expect most Tomcat developers 
would consider the assertion mechanism irrelevant at this point in time, 
because Tomcat needs to run on JDK 1.3 (and even 1.2).

>I understand it is not a pressing problem for Apache developers as
>assertions require a minimum of java1.4; while 1.2 or 1.3 support is
>required of apache projects it is only a theoretical problem - unless
>there are people like me who are fans of assertions.
>
>  
>
I'm *not* a fan of assertions in my production code, at least partly 
because of this issue.  I'm a big fan of assertions (JUnit style) in my 
unit tests.

>I'm happy to change to using a RuntimeException subclass if that is the
>general consensus. 
>
>  
>
+1.

IMHO, things like IllegalArgumentException and NullPointerExcepton are 
not "Errors" for a reason; they are "Exceptions" -- caused by either the 
user botching their use of your class, or your class botching its 
specified contracts.  In most cases, they represent conditions that you 
should be able to, or should at least try to, recover from.

Error is (to quote the Javadocs) "a subclass of Throwable that indicates 
serious problems that a reasonable application should not try to 
catch."  Lumping AssertionError into that definition is pretty 
problematic -- I'd probably never knowingly run an app with assertions 
enabled in production.

>Simon
>
>  
>
Craig



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message