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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
