I guess I'm too late to argue this one any more but here's my 2 pennies for what its worth.
From: "Morgan Delagrange" <[EMAIL PROTECTED]> > Hi all, > > I'm going to talk about Jelly Exception > handling...again. :) I'd like permission to try to > weed out nearly all of our instances of > throwing/catching generic Exceptions and Throwables. > IMO explicit error handling is better than just > throwing Exception. It makes the possible problems in > your application much more clear. It makes it easier > to distinguish between recoverable and unrecoverable > error. It makes it safer to change the application, > because you're aware when you introduce new types of > Exceptions to your application. It's just a good > thing. Thats certainly true in general. > I'd like to try the following steps: > > 1) Replace the generic Exception calls from all method > signatures EXCEPT TAGS with JellyException. In some > cases, there may be a more appropriate exception than > JellyException (e.g. InstantiationException, > ClassNotFoundException, etc.) > > 2) Replace the generic Exception calls in the tag > method signatues with JellyTagException, which will be > a subclass of JellyException. I'm in total agreement in general - however I disagree about the Tag interface change. The only class which will ever be invoking the Tag.doTag() method is the TagScript class. So there's only 1 piece of code typically that this method is invoked. The reason I made the decision to go with throws Exception was so that Tag developers don't have to bother catching whatever checked exceptions get thrown when they do their stuff and then wrapping them in some other exception. The TagScript does that automatically in one place. I agree that this is not standard OO practice but then Tags were not meant to be standard OO objects interspersed around your application code - rather standard OO code would invoke Jelly Scripts via the JellyContext or Script interfaces. Pretty much any tag of any complexity is gonna do something which may thrown an exception. Forcing all tags to catch all these exceptions and wrap them in some wrapper exception didn't seem to add much value and seems to add extra work to the tag author for little gain IMHO. Pretty much all APIs do this (JSP, Ant, Servlets etc). Though in something like Jelly it just didn't feel right - it seems unnecessary work for the Tag authors. Also from an efficiency point of view, the TagScript needs to catch exceptions anyway, to append the location information into the wrapped JellyException - so it seems silly to have a double catch block. Most importantly I didn't want to break all the tag implementations out there in Maven, drools, werkflow and alsorts of other places. So I was gonna vote -1 mostly of the latter reason. I'm not so concerned about the other reasons that I'd try to veto this move. Though since I'm quite late to the party (had a very busy week) and most of the works been done already I'm -0 on this. Though please can someone help out fixing the other libraries - particularly the Maven ones. Right now I can't build Maven or Jelly as both are busted (I can't build Maven as its Jelly tags are busted, so I can't get a recent build of Maven to build Jelly). > 3) Weed out most of the try/catch blocks in the bodies > of our methods that catch Exception or Throwable. I > will replace them with the specific Exceptions they > catch (probably JellyException in most cases). Agreed - catching Throwable is bad. Also JellyContext and Script interfaces should not throw Exception. I'm agreeing with you in these moves, just agreeing to disagree about the Tag interface change - but am not disagreeing that strongly - more explaining why I made the choices I did. James ------- http://radio.weblogs.com/0112098/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
