commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <si...@ecnetwork.co.nz>
Subject Re: [digester] assertion mechanism throws Error [was: plugins module ready for evaluation]
Date Mon, 27 Oct 2003 22:41:25 GMT
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?

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 happy to change to using a RuntimeException subclass if that is the
general consensus. 

Simon


---------------------------------------------------------------------
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