tiles-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Reddin" <gred...@gmail.com>
Subject Re: svn commit: r637434 [1/2] - in /tiles/framework/trunk: tiles-api/src/main/java/org/apache/tiles/ tiles-api/src/main/java/org/apache/tiles/access/ tiles-api/src/main/java/org/apache/tiles/mgmt/ tiles-api/src/test/java/org/apache/tiles/access/ tile
Date Mon, 17 Mar 2008 16:21:27 GMT
On Mon, Mar 17, 2008 at 10:02 AM, Antonio Petrelli
<antonio.petrelli@gmail.com> 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

Mime
View raw message