James, I have a buildable version of Maven on my hard disk waiting for the jelly snapshots to get uploaded to ibiblio.
I've also uploaded werkz-1.0-beta6 to ibiblio that uses the new api. -- dIon Gillard, Multitask Consulting Blog: http://www.freeroller.net/page/dion/Weblog Work: http://www.multitask.com.au "James Strachan" <[EMAIL PROTECTED]> wrote on 29/01/2003 12:32:44 AM: > 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] > > ForwardSourceID:NT000A9AA6 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
