On Tue, 2003-10-28 at 12:12, robert burrell donkin wrote: > On Monday, October 27, 2003, at 10:41 PM, Simon Kitching wrote:
Just a note: I'm mostly on the side of a RuntimeException-based approach already. I just proposed an Error-based exception to ensure the issue was debated. A shame the "debate" is Robert & me so far.. If no-one can mount a good defence of the Java-1.4-like Error-based approach, I will happily prepare a patch. [Robert: If you could commit the logging patch submitted earlier today, that would make it easier to create the patch, hint, hint :-]. > > i like assertions but i don't want error's thrown from library code when > it's used in production. Well, I'll have a final stab at arguing the toss on this topic.. It seems the difference between the existing plugins code and the equivalent implementation using java 1.4 assertions in "production" mode is: * the current plugins approach would throw Error, which may have nasty side-effects on the container, vs * the java 1.4 assertion mechanism would have been disabled, so the code would zoom straight past the point at which the assertion would have detected invalid state, and kept on going with unpredictable consequences. It's tough to have to choose between these options! NB: If the java 1.4 assertions are not disabled, then the two implementations behave identically. Personally, I think the JSR assertion group got it wrong. Assertion failures should indeed throw a RuntimeException subclass. Then it would not be any great problem to leave assertions enabled in production code (providing the performance hit was acceptable) without the nasty problems that Robert described. I didn't want to say so at first, because a "RuntimeException" approach would probably have been accepted without comment, and I hoped to get some comment for/against the two options. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
