[email protected]
[Top] [All Lists]

Re: Custom Exception Hierarchy and Custom Exception Page

Subject: Re: Custom Exception Hierarchy and Custom Exception Page
From: Kent Tong
Date: Mon, 21 Mar 2005 01:55:09 +0000 UTC
Konstantin Ignatyev <kgignatyev <at> yahoo.com> writes:

> What a nonsense! What really breaks encapsulation is
> the extending and using RuntimeExceptions! That really
> breaks everything and hides potential problems from
> developers.

To keep this topic related to Tapestry, let's consider
how Tapestry uses exceptions. ApplicationRuntimeException
extends RuntimeException. Most other exception classes
extend ApplicationRuntimeException. So, most of the 
Tapestry code uses RuntimeException. That's why we don't
see the clumsy throws clause for most methods and more
importantly we don't need to catch or rethrow any 
exception in which we aren't really interested in our 
own code.

In addition, many (most?) other successfully projects
also don't use checked exceptions, eg, Spring, Hibernate 3,
JBoss, JDO (endorsed by SUN!), Xerces, JUnit, HtmlUnit.

> It is very simple: if error is not recoverable
> programmatically by any means (OutOfMemory) - then it
> is RuntimeException, if recovery is possible then it
> should be some kind of CheckedException.

Then a PageRedirectException (which ultimately extends 
RuntimeException) is programtically unrecoverable?

To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

<Prev in Thread] Current Thread [Next in Thread>