commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [digester] assertion mechanism throws Error [was: plugins module ready for evaluation]
Date Mon, 27 Oct 2003 23:12:02 GMT
On Monday, October 27, 2003, at 10:41 PM, 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.

they were smart enough to allow assertions to be turned off for production 

i had considered suggesting a system property flag but it seems like it'd 
require a lot of explanation for such a small feature.

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

the place where this kind of thing used to be debated was on general. 
(commons-dev is pretty high volume and i'd say it's a bit impolite posting 
to everyone.) but there are quite a few people who read digester who might 
like to jump in now.

> 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 like assertions but i don't want error's thrown from library code when 
it's used in production.

- robert

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message