struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Laine Donlan" <ldon...@elogex.com>
Subject RE: Declarative Exception Handling
Date Mon, 03 Dec 2001 21:12:43 GMT
Couple of comments in-line -

-----Original Message-----
From: Ted Husted [mailto:husted@apache.org]
Sent: Monday, December 03, 2001 3:15 PM
To: Struts Developers List
Subject: Re: Declarative Exception Handling


Dimitri Valdin wrote:
> Since I see no reason to define hundreds of different exceptions,
> which are very similar in their nature and are handled in a similar
way,
> I would propose:
> 
> *) introduce 2 base exception classes: AppException and
RuntimeException
> which should support constructors like:
> 
> AppException("error.password.mismatch");
> AppException("database.load", "myDatabase");
> 
> with entries in application properties
> 
> error.password.mismatch=<li>Invalid username and/or password, please
try again</li>
> database.load=Cannot load database from {0}
> 
> *) extend Laine's approach with following configuration option:
> 
> <global-exceptions>
>     <exception type="org.apache.struts.exceptions.AppException"/>
>     <exception type="org.apache.struts.exceptions.RuntimeException"
path="error.jsp"/>
> </global-exceptions>
> 
> - you would stay on the same page in case of all application
exceptions
> - you would be forwarded to error.jsp in case of runtime exceptions
> - hadling of some particular exception can be added as well
> 
> If the exeption key is specified, then the handling will be as Laine
has proposed.
> If no exception key is specified, then the exception.getMessage()
> will be used as a key for a lookup. exception.getValues() returns
> the array of values which can be passed to messages.getMessage():
> 
> MessageResources messages =
MessageResources.getMessageResources("Exceptions");
> messages.getMessage(super.getMessage(), values);
> 
> This stuff can be implemented within the basis exception class.
>
> If it is OK, then I can try to modify the code to introduce the
changes.


+1, but with with exception chaining for those not using 1.4

http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-exceptions.html

- This makes perfect sense.  I have also been toying with the idea of
- Adding another configuration property to the exceptions (i.e Handler).
- This would just be a further hook into the process allowing for more
- granular handling above page flow.  For example - if an AppException
occurred
- and was handled by a global mapping should an admin maybe get an email
- 
- why not define a class (optionally) to perform the handling.  This
would
- alleviate the requirement that the controller assume how exceptions be
handled 
- for every application.
-
-

> It would mean, that Action classes should derive not from
action.Action,
> but from action.DispatchExceptionAction. It is exactly what we have
> done, while introducing our base action class. Personally I think,
that
> it is quite wise to create such base action for your project.
> You can put some additional stuff in it, which can be usefull in your
> application. ActionServlet is also a candidat for deriving from.
> For example to configure log4j.

This is probably the only recourse for now. Perhaps we can work the
support code into the base Action class, so people could extend Action
and then work this pattern into their existing base classes. Many people
are already using some variation of "doPerform".

- After first implementing this in an Action, I would question how
- deep the provided Action hierarchy should be.  As is stated -
- 'it is quite wise to create a such base action for your project' -
- but the wider the possibilities for decendance the more application
- specific base classes may be needed.  Personally, after moving away
from the
- the base action implemented handling to the controller based handling 
- our application has been cleaned up quite a bit.  It is less code that
- needs to be maintained by Actions and is purely a service provided
- by the controller.



> perhaps some time later nobody will remind old perform(), but would
use
> new execute() ;-)

OK by me, especially if the controller were somehow smart enough to call
one or the other if both approaches were mixed in the same application
(during a migration period).

- Isn't this kind of handled by having the base Action pass off to the
execute?
- This pretty much leaves it up to the application developer which
services to use?



-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/

--
To unsubscribe, e-mail:
<mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:struts-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message