Re: Struts Error Page Approach - Recommended / Struts Support
Hi Paul! Can you send a sample file? Your workaround seems interesting. Regards, L. Yeung --- Paul Dillon [EMAIL PROTECTED] wrote: You need two strategies - one for errors you can handle and recover from, and another for everything else. For errors I can handle (includes exceptions and business-level validations), I describe the problem in plain english, stick it into a string attribute on the request object, then I forward to the previous screen. On each screen I include a messages page which displays these messages as well as any ActionErrors. I also use this for success messages. If you need i18n, a better approach would be to use the ActionMessage instead of strings (but they came along sometime after the 1.0 release). For errors I don't handle, I throw servlet exceptions. At the moment I haven't bothered with an error page, though I intend to set up a page in my web.xml that catches all java.lang.Exception's, displays the error, and provides a button or link to hop back to the start page of the web-app. How is everyone else handling it? - Paul - Original Message - From: Greg Callaghan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 28, 2001 1:40 PM Subject: Struts Error Page Approach - Recommended / Struts Support Hi, Wondering what the typical struts approach is to handling and passing back errors to the user is. I'm not talking about ActionForm validation, but rather the situation where an Action determines there is a error (ie either directly itself or via an exception from a business object). What is recommended approach with struts? - use of servlet errorpage specified in Web.xml? (not sure how this works yet, still have to find good doco) - use of struts errorpage as GLOBAL FORWARD to JSP which assumes maybe a ERROR_MESSAGE in request scope? - incorporate use of struts validation error infrastruture somehow? (eg re-use ActionErrors perhaps)? - would creating an ActionError in the Action itself and forwarding back to the original JSP page be possible in the case where there is not normally form validation on this page. ie leverage off ability to put html:errors/ in JSP just to handle presentation of backend errors (ie not formbean validation errors). I'm assuming the general approach overall is to throw business logic errors up the chain until hitting the Action classes so one may then present an appropriate error message to the user (via one of the approaches above?). cheers Greg _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Error Page Approach - Recommended / Struts Support
I basically do the same thing as Paul. My business objects throw
their own exceptions, which I can catch. These exception classes
are chained and often include more than one message: the initial
cause and my business explanation. I use the ActionError class to
send this to the JSP. Since they ActionError can handle a queue of
messages, I start with a generic Oops message, followed by the
more specific business error, followed by the geek-speak initial
cause. This way everybody is happy!
ActionErrors errors = new ActionErrors();
ModelResult modelResult = null;
try {
modelResult = getResult(
mapping,form,request,response,helpers);
}
catch (ModelException e) {
// Log and print to error console
servlet.log(Model Exception: , e );
e.printStackTrace();
// General error message
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError(error.general));
// Generate error messages from exceptions
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError(error.detail,e.getMessage()));
if (e.isCause()) {
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError(error.detail,e.getCauseMessage()));
}
}
The error.detail is one big replacement parameter
error.detail={0}
Then I look for an input mapping, and use that for the error
page if there is one. If not, I look for a generic error page instead.
// -- Report any errors
if (!errors.empty()) {
saveErrors(request, errors);
if (mapping.getInput()!=null)
return (new ActionForward(mapping.getInput()));
// If no input page, use error forwarding
return (mapping.findForward(Tokens.ERROR));
}
The chained exception class is based on Brian Goetz' class.
http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-exceptions.html
-Ted.
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Error Page Approach - Recommended / Struts Support
Thanks Ted Paul.
As always, a useful piece of the puzzle.
Just wondering what you need the isCause() method. I
read the article about exception handling, but when
you write the detail message -- won't this write the
cause out for you?
Where would you not have the cause?
Also: the business error -- is it the last one thrown
or the first? The cause: is this the last one thrown
or the first?
thanks,
Sandeep
--- Ted Husted [EMAIL PROTECTED] wrote:
I basically do the same thing as Paul. My business
objects throw
their own exceptions, which I can catch. These
exception classes
are chained and often include more than one
message: the initial
cause and my business explanation. I use the
ActionError class to
send this to the JSP. Since they ActionError can
handle a queue of
messages, I start with a generic Oops message,
followed by the
more specific business error, followed by the
geek-speak initial
cause. This way everybody is happy!
ActionErrors errors = new ActionErrors();
ModelResult modelResult = null;
try {
modelResult = getResult(
mapping,form,request,response,helpers);
}
catch (ModelException e) {
// Log and print to error console
servlet.log(Model Exception: , e );
e.printStackTrace();
// General error message
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError(error.general));
// Generate error messages from exceptions
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError(error.detail,e.getMessage()));
if (e.isCause()) {
errors.add(ActionErrors.GLOBAL_ERROR,
new
ActionError(error.detail,e.getCauseMessage()));
}
}
The error.detail is one big replacement parameter
error.detail={0}
Then I look for an input mapping, and use that for
the error
page if there is one. If not, I look for a generic
error page instead.
// -- Report any errors
if (!errors.empty()) {
saveErrors(request, errors);
if (mapping.getInput()!=null)
return (new ActionForward(mapping.getInput()));
// If no input page, use error forwarding
return (mapping.findForward(Tokens.ERROR));
}
The chained exception class is based on Brian Goetz'
class.
http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-exceptions.html
-Ted.
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Error Page Approach - Recommended / Struts Support
Sometimes there is only a business exception, other times there is an
underlying exception followed by a business exception. So the business
object is thrown a SQL error, wraps it, and throws its own version.
Other times, there can be a business logic error that doesn't wrap
anything else.
Sandeep Takhar wrote:
Thanks Ted Paul.
As always, a useful piece of the puzzle.
Just wondering what you need the isCause() method. I
read the article about exception handling, but when
you write the detail message -- won't this write the
cause out for you?
Where would you not have the cause?
Also: the business error -- is it the last one thrown
or the first? The cause: is this the last one thrown
or the first?
thanks,
Sandeep
--- Ted Husted [EMAIL PROTECTED] wrote:
I basically do the same thing as Paul. My business
objects throw
their own exceptions, which I can catch. These
exception classes
are chained and often include more than one
message: the initial
cause and my business explanation. I use the
ActionError class to
send this to the JSP. Since they ActionError can
handle a queue of
messages, I start with a generic Oops message,
followed by the
more specific business error, followed by the
geek-speak initial
cause. This way everybody is happy!
ActionErrors errors = new ActionErrors();
ModelResult modelResult = null;
try {
modelResult = getResult(
mapping,form,request,response,helpers);
}
catch (ModelException e) {
// Log and print to error console
servlet.log(Model Exception: , e );
e.printStackTrace();
// General error message
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError(error.general));
// Generate error messages from exceptions
errors.add(ActionErrors.GLOBAL_ERROR,
new ActionError(error.detail,e.getMessage()));
if (e.isCause()) {
errors.add(ActionErrors.GLOBAL_ERROR,
new
ActionError(error.detail,e.getCauseMessage()));
}
}
The error.detail is one big replacement parameter
error.detail={0}
Then I look for an input mapping, and use that for
the error
page if there is one. If not, I look for a generic
error page instead.
// -- Report any errors
if (!errors.empty()) {
saveErrors(request, errors);
if (mapping.getInput()!=null)
return (new ActionForward(mapping.getInput()));
// If no input page, use error forwarding
return (mapping.findForward(Tokens.ERROR));
}
The chained exception class is based on Brian Goetz'
class.
http://www.javaworld.com/javaworld/jw-08-2001/jw-0803-exceptions.html
-Ted.
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
__
Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
-- 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]
RE: Struts Error Page Approach - Recommended / Struts Support
a combination of 2 and 4 works well. ie, put together ActionErrors, forward to the page where they are displayed with html:errors/ Of course, you don't have to use ActionErrors - and list will do, but why not? :) - Brett -Original Message- From: Greg Callaghan [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 28 November 2001 1:41 PM To: [EMAIL PROTECTED] Subject: Struts Error Page Approach - Recommended / Struts Support Hi, Wondering what the typical struts approach is to handling and passing back errors to the user is. I'm not talking about ActionForm validation, but rather the situation where an Action determines there is a error (ie either directly itself or via an exception from a business object). What is recommended approach with struts? - use of servlet errorpage specified in Web.xml? (not sure how this works yet, still have to find good doco) - use of struts errorpage as GLOBAL FORWARD to JSP which assumes maybe a ERROR_MESSAGE in request scope? - incorporate use of struts validation error infrastruture somehow? (eg re-use ActionErrors perhaps)? - would creating an ActionError in the Action itself and forwarding back to the original JSP page be possible in the case where there is not normally form validation on this page. ie leverage off ability to put html:errors/ in JSP just to handle presentation of backend errors (ie not formbean validation errors). I'm assuming the general approach overall is to throw business logic errors up the chain until hitting the Action classes so one may then present an appropriate error message to the user (via one of the approaches above?). cheers Greg _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Struts Error Page Approach - Recommended / Struts Support
You need two strategies - one for errors you can handle and recover from, and another for everything else. For errors I can handle (includes exceptions and business-level validations), I describe the problem in plain english, stick it into a string attribute on the request object, then I forward to the previous screen. On each screen I include a messages page which displays these messages as well as any ActionErrors. I also use this for success messages. If you need i18n, a better approach would be to use the ActionMessage instead of strings (but they came along sometime after the 1.0 release). For errors I don't handle, I throw servlet exceptions. At the moment I haven't bothered with an error page, though I intend to set up a page in my web.xml that catches all java.lang.Exception's, displays the error, and provides a button or link to hop back to the start page of the web-app. How is everyone else handling it? - Paul - Original Message - From: Greg Callaghan [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, November 28, 2001 1:40 PM Subject: Struts Error Page Approach - Recommended / Struts Support Hi, Wondering what the typical struts approach is to handling and passing back errors to the user is. I'm not talking about ActionForm validation, but rather the situation where an Action determines there is a error (ie either directly itself or via an exception from a business object). What is recommended approach with struts? - use of servlet errorpage specified in Web.xml? (not sure how this works yet, still have to find good doco) - use of struts errorpage as GLOBAL FORWARD to JSP which assumes maybe a ERROR_MESSAGE in request scope? - incorporate use of struts validation error infrastruture somehow? (eg re-use ActionErrors perhaps)? - would creating an ActionError in the Action itself and forwarding back to the original JSP page be possible in the case where there is not normally form validation on this page. ie leverage off ability to put html:errors/ in JSP just to handle presentation of backend errors (ie not formbean validation errors). I'm assuming the general approach overall is to throw business logic errors up the chain until hitting the Action classes so one may then present an appropriate error message to the user (via one of the approaches above?). cheers Greg _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
