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
> 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".
> 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).
-- 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
