On Mon, Mar 17, 2008 at 10:02 AM, Antonio Petrelli <[EMAIL PROTECTED]> wrote: > > Sorry if I seem rude, but I think that the choice of using only checked > exceptions was a wrong choice.
Nope, not rude at all, just a stylistic difference, and one I'm willing to rethink. > If you take a look on where TilesException > (and its extended exceptions) is thrown, you may notice that, in fact, they > are all configuration exceptions (errors in xml files, problems with > instantiations, etc.). So you want to see cleaner code by not having to wrap that sort of thing in a try...catch block? As Nathan pointed out, it would likely be a try...catch that you can't recover from. IOW, it would be a situation where you need to see a dramatic explosion that indicates very plainly that you have a configuration problem. But you don't want to clutter your code by wrapping the possibility of a configuration problem you can't do anything about in an exception handler. That makes sense. > For example, take Hibernate, where everything may throw an unchecked > exception: this helps a lot in finding bugs. I honestly didn't realize HibernateException was a RuntimeException until just now. And I looked at my code which uses the Hibernate API and all I can do is log an error in the places where I catch HibernateException. Hmmm. I'll take a closer look at the change in that light. If it still bothers me I'll let you know. Thanks, Greg
