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]

Reply via email to