You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "matthew c. mead" <m-...@goof.com> on 2005/03/18 20:37:39 UTC
Custom Exception Hierarchy and Custom Exception Page
Taking a break from the mailing list vs. forum thread for a while...
Apologies if this is a repeat, but I can't find much in specific in the
list archives that fit what I'm looking for.
I have a hierarchy of application specific exception types. In the
past, on struts projects, I have used the template-method pattern to
have all my actions throw these exceptions - the base class for my
actions would catch exceptions based on the base class of the exception
hierarchy and route to appropriate "user-friendly" exception pages based
on specific classes, perform actions that might be able to correct for
the condition, etc.
In Tapestry, I'd like to throw these exceptions from all manner of
places: listeners, render listeners, page validation methods, etc.
However, the method signatures on the interfaces specifying these
methods have no throws clause.
It seems to me the only way to do this is to wrap them all in a
RuntimeException and extract them from that within my application's
custom exception handling page.
Is this what others have done? Is there another good option I'm not seeing?
Thanks!
-matt
--
matthew c. mead
http://www.goof.com/
Re: Custom Exception Hierarchy and Custom Exception Page
Posted by Kent Tong <ke...@cpttm.org.mo>.
matthew c. mead <m-apache <at> goof.com> writes:
> Good point. Why is it better, though? Less object creation? The
> problem I have with my framework exceptions extending RuntimeException
> is that by doing so I can end up being sloppy about properly handling
> errors. If I'm forced to declare them thrown and catch them I can
> ensure consistency in error handling throughout the business layer of
> the application.
This issue (checked vs uncheck exceptions) has been brought up
at various places. Checked exception breaks encapsulation,
causes information loss and information overload. For the details,
please read:
http://www.octopull.demon.co.uk/java/ExceptionalJava.html
http://www.mindview.net/Etc/Discussions/CheckedExceptions
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Custom Exception Hierarchy and Custom Exception Page
Posted by "matthew c. mead" <m-...@goof.com>.
Kent Tong wrote:
>matthew c. mead <m-apache <at> goof.com> writes:
>
>
>
>>The main issue I was wondering about was whether the approach had to be
>>"wrap the exception in a RuntimeException." It sounds like it is.
>>
>>
>
>No, it isn't. A better way is to let your exception classes extend
>RuntimeException.
>
>
>
Good point. Why is it better, though? Less object creation? The
problem I have with my framework exceptions extending RuntimeException
is that by doing so I can end up being sloppy about properly handling
errors. If I'm forced to declare them thrown and catch them I can
ensure consistency in error handling throughout the business layer of
the application.
-matt
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Custom Exception Hierarchy and Custom Exception Page
Posted by Kent Tong <ke...@cpttm.org.mo>.
matthew c. mead <m-apache <at> goof.com> writes:
> The main issue I was wondering about was whether the approach had to be
> "wrap the exception in a RuntimeException." It sounds like it is.
No, it isn't. A better way is to let your exception classes extend
RuntimeException.
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Custom Exception Hierarchy and Custom Exception Page
Posted by "matthew c. mead" <m-...@goof.com>.
I definitely believe in the reuse of code and standard exceptions as
well. In my particular case, I want a foolproof mechanism to determine
if my application framework threw an exception or the tapestry framework
threw an exception. Hence I have another RuntimeException subclass to
wrap my framework's exceptions. Using instanceof, I can quickly
determine whether to do more processing to try and "handle" the
exception, report it in a way meaningful way that allows the user to
contact support and give them enough information to start finding the
problem, or lump it into some "unknown" type category where I log
everything I can about it in hopes of a developer sorting it out later.
The main issue I was wondering about was whether the approach had to be
"wrap the exception in a RuntimeException." It sounds like it is.
Thanks!
-matt
Bryan Lewis wrote:
>That's the only good option I'm aware of.
>
>I've been somewhat lazy by using Tapestry's ApplicationRuntimeException for
>my exception wrapper. I'm not sure this is best practice... I probably
>should be defining my own app-level exception when the cause is unrelated to
>Tapestry. In the book "Effective Java", for example, Item 43 says, Throw
>exceptions appropriate to the abstraction. On the other hand, Item 42 says,
>Favor the use of standard exceptions to achieve a high degree of code reuse,
>so I've got an excuse.
>
>
>----- Original Message -----
>From: "matthew c. mead" <m-...@goof.com>
>To: "Tapestry users" <ta...@jakarta.apache.org>
>Sent: Friday, March 18, 2005 2:37 PM
>Subject: Custom Exception Hierarchy and Custom Exception Page
>
>
>
>
>>Taking a break from the mailing list vs. forum thread for a while...
>>
>>Apologies if this is a repeat, but I can't find much in specific in the
>>list archives that fit what I'm looking for.
>>
>>I have a hierarchy of application specific exception types. In the
>>past, on struts projects, I have used the template-method pattern to
>>have all my actions throw these exceptions - the base class for my
>>actions would catch exceptions based on the base class of the exception
>>hierarchy and route to appropriate "user-friendly" exception pages based
>>on specific classes, perform actions that might be able to correct for
>>the condition, etc.
>>
>>In Tapestry, I'd like to throw these exceptions from all manner of
>>places: listeners, render listeners, page validation methods, etc.
>>However, the method signatures on the interfaces specifying these
>>methods have no throws clause.
>>
>>It seems to me the only way to do this is to wrap them all in a
>>RuntimeException and extract them from that within my application's
>>custom exception handling page.
>>
>>Is this what others have done? Is there another good option I'm not
>>
>>
>seeing?
>
>
>>Thanks!
>>
>>
>>
>>
>>-matt
>>
>>--
>>matthew c. mead
>>
>>http://www.goof.com/
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
--
matthew c. mead
http://www.goof.com/
Re: Custom Exception Hierarchy and Custom Exception Page
Posted by Bryan Lewis <br...@maine.rr.com>.
That's the only good option I'm aware of.
I've been somewhat lazy by using Tapestry's ApplicationRuntimeException for
my exception wrapper. I'm not sure this is best practice... I probably
should be defining my own app-level exception when the cause is unrelated to
Tapestry. In the book "Effective Java", for example, Item 43 says, Throw
exceptions appropriate to the abstraction. On the other hand, Item 42 says,
Favor the use of standard exceptions to achieve a high degree of code reuse,
so I've got an excuse.
----- Original Message -----
From: "matthew c. mead" <m-...@goof.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Friday, March 18, 2005 2:37 PM
Subject: Custom Exception Hierarchy and Custom Exception Page
> Taking a break from the mailing list vs. forum thread for a while...
>
> Apologies if this is a repeat, but I can't find much in specific in the
> list archives that fit what I'm looking for.
>
> I have a hierarchy of application specific exception types. In the
> past, on struts projects, I have used the template-method pattern to
> have all my actions throw these exceptions - the base class for my
> actions would catch exceptions based on the base class of the exception
> hierarchy and route to appropriate "user-friendly" exception pages based
> on specific classes, perform actions that might be able to correct for
> the condition, etc.
>
> In Tapestry, I'd like to throw these exceptions from all manner of
> places: listeners, render listeners, page validation methods, etc.
> However, the method signatures on the interfaces specifying these
> methods have no throws clause.
>
> It seems to me the only way to do this is to wrap them all in a
> RuntimeException and extract them from that within my application's
> custom exception handling page.
>
> Is this what others have done? Is there another good option I'm not
seeing?
>
>
> Thanks!
>
>
>
>
> -matt
>
> --
> matthew c. mead
>
> http://www.goof.com/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org