Morgan Delagrange wrote:
Hi all,As a user, I have one comment about the above. In some cases, many exception types go together, like the two you mention which relate to class loading and getting an instance, and I have found that in cases like that I tend to just catch the Throwable anyway as I just need to know that the class couldn't be instantiated. For example in places where I use BeanUtils and it throws like 4 or 5 exceptions that are all basically the same end cause I don't want to catch all of them individually. In those cases I would rather have one JellyException to catch, which I can log/rethrow, etc.
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.
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.)
It may not be 'correct', but if I'm using Jelly and something happens under the covers, like a tag not loading a class, then I want Jelly to tell me, not java.lang.*Exception.
I DO agree with this one and the next one. To me a framework/API should probably not throw Exception or Throwable on its own. Just looks like laziness...2) Replace the generic Exception calls in the tag method signatues with JellyTagException, which will be a subclass of JellyException.
Just my 2 cents..
Robert McIntosh
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).
Steps 1 and 3 can probably be made without impacting
too many users. Step 2, on the other hand, will
probably require changes to most of our tag
implementations in Jelly, and probably some of the
tags in Maven and Latka as well. I'm willing to take
on as much of the Jelly and Latka work as necessary,
and I can help with the Maven tags.
I realize this is sort of a pain, but I think it's
worth doing before release. I'd like to give it a
shot. Comments?
- Morgan
=====
Morgan Delagrange
http://jakarta.apache.org/taglibs
http://jakarta.apache.org/commons
http://axion.tigris.org
http://jakarta.apache.org/watchdog
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
