Re: Handling Exceptions in ActionForm
At your own risk, manipulate the ActionErrors and ActionMessages collections any way
you like.
They're in the request scope and named according to Globals.ERROR_KEY and
Globals.MESSAGE_KEY.
m
--- Shane Mingins [EMAIL PROTECTED] wrote:
Hi
I have a Swing app where the SwingView implements the view interface and has
a method duplicateException(String s).
In the SwingView it is implemented as
public void duplicateException(String duplicateName)
{
JOptionPane.showMessageDialog(this, That would result in a duplicate
Channel, Duplicate Channel,
JOptionPane.ERROR_MESSAGE);
}
So if the business layer finds a duplicate it can inform the presentation
layer. I am wondering how this would map on Struts?
Using Struts, if I have an ActionForm implement the view interface, how
would it create an ActionError or ActionMessage? It seems that from an
ActionForm the validate() method can do it, and an Action can do it but is
it possible to create an ActionError and save it from my
duplicateException() method?
Could I perhaps have my duplicateException() method add to collection
variable in the ActionForm and then have the validate() method check that
collection and generate the required ActionErrors?
Any thoughts?
Shane
Shane Mingins
Analyst Programmer
Assure NZ Ltd
Ph 644 494 2522
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Handling Exceptions in ActionForm
-Original Message- From: Shane Mingins [mailto:[EMAIL PROTECTED] Using Struts, if I have an ActionForm implement the view interface, how would it create an ActionError or ActionMessage? It seems that from an ActionForm the validate() method can do it, and an Action can do it but is it possible to create an ActionError and save it from my duplicateException() method? Any validation logic in the ActionForm should only be basic syntactical validation, and no semantic validation. Semantic validation belongs in your Action class, and likely in business logic called from your Action class. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Handling Exceptions
For ServletException, configure the error page in web.xml file. it will work. navjot |-Original Message- |From: Mohd Amin Mohd Din [mailto:[EMAIL PROTECTED] |Sent: Sunday, August 31, 2003 5:12 PM |To: [EMAIL PROTECTED] |Subject: Handling Exceptions | | |Hi, | |In struts-config, I have defined few global-exceptions such as these | | exception type=com.enc.edu.pg.bo.common.DataAccessException | key=exception.common.dataaccessexception | path=/action/main/dataAccessExceptionSetup | scope=session | /exception | exception type=java.lang.Exception | key=exception.common.exception | path=/action/main/errorSetup | scope=session | /exception | exception type=javax.servlet.ServletException | key=exception.common.servletexception | path=/action/main/errorSetup | scope=session | /exception | |I also have created an error page, error.jsp with %@ page |isErrorPage=true % and at the top of the jsp template for all the |pages a %@ page errorPage=error.jsp %. However, when a |ServletException occurs, it does not go to the path defined in |struts-config.xml. Somehow, the error is still showing in the |application page and not in any one of the error pages defined. | |Thanks |Amin | | | - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling Exceptions
However, when a ServletException occurs, it does not go to the path defined in struts-config.xml. Somehow, the error is still showing in the application page and not in any one of the error pages defined. My guess is, the ServletException is happening someplace where Struts' ExceptionHandler can't get hold of it, e.g. on your JSP page. Have a look at your servlet container's logfiles to see exactly where they appear. You can still define an error-page in your *web.xml* to catch those and redirect them to your own error-page. HTH, Yann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling Exceptions
You should probably create a global exception handler in your Struts configuration file. Something like this: global-exceptions exception key=global.error.internal path=/ErrorPage.jsp scope=request type=java.lang.Exception/ /global-exceptions hope this helps --Alen - Original Message - From: Syed Kazim Hussain [EMAIL PROTECTED] To: 'Struts Users Mailing List' [EMAIL PROTECTED] Sent: Thursday, June 19, 2003 7:52 AM Subject: Handling Exceptions I have been using Struts as the MVC framework and Sitemesh as templates. It is working smoothly. Only problem is I want to forward the page to an error page whenever there is an exception. So in Tomcat, I have specified the option for forwarding the request to ErrorPage.jsp whenever we encounter a 500 Internal Server Error. But the page is not being forwarded. Instead an exception is thrown on the Error Page: java.lang.IllegalStateException: getOutputStream() has already been called for this response Any comments ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Handling exceptions in Action class
Take a look at my draft chapter on ExceptionException and see if that sheds any light on the topic. You can download it here: http://www.theserverside.com/resources/strutsreview.jsp It's Chapter 10. You will need to register, but it's free. Chuck Hi all: Can anyone kindly suggest, if i want to handle exceptions in the perform method of the Action class (like LogonAction class), how should I go go about? I thought of instantiating a ErrorAction Class from the perform method and pass parameters which would do the logging in the log file..(I want to log the exceptions in a log file.) I am not too sure of how to go about... Kindly suggest.. TIA Vijeth -- 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]
RE: Handling exceptions
Hmm, well, I think you should care about that. If a JVM exception happens, there is most probably something wrong going on. If you don't catch the exception/error, your user will get an ugly 505 server error or something like that. Your decision will depend on whether this is okay in your application or not (from a product management point of view). In our case, it was not. We prepared a nicely formatted Error page with phone numbers and contact information apologizing for the inconvenience ... etc. We forward to this Error page is served whenever an abnormal exception takes place, i.e., when we end up in the catch Throwable block in validate() or in perform(). Hani. -Original Message- From: Dariusz Wojtas [mailto:[EMAIL PROTECTED]] Sent: Monday, March 04, 2002 4:06 PM To: Struts Users Mailing List Subject: RE: Handling exceptions OK, that was helpful - now I see it from different perspective. But what if somebody argues that Throwable catches also JVM exceptions, like ThreadDeath or OutOfMemory and similar? Should I care about that or not? If not then why? Dariusz Wojtas At 13:14 02-03-04 -0500, you wrote: Catching Throwable will catch both Exceptions and Errors. Catching Exception will only catch Exceptions. You will want to catch Exceptions *AND* Errors to be bullet-proof. We were catching Exception for a while and we thought we were covered, until one day we got (due to some weird deployment) a NoClassDefFoundError, which of course escaped the catch Exception and barfed right in front of the user in their browser as an ugly 505. So I think catch Throwable should be your final catch-all after you have handled all your normal exceptions. Good luck, Hani. -- 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]
RE: Handling exceptions
Catching Throwable will catch both Exceptions and Errors. Catching Exception
will only catch Exceptions.
You will want to catch Exceptions *AND* Errors to be bullet-proof.
We were catching Exception for a while and we thought we were covered, until
one day we got (due to some weird deployment) a NoClassDefFoundError, which
of course escaped the catch Exception and barfed right in front of the
user in their browser as an ugly 505.
So I think catch Throwable should be your final catch-all after you have
handled all your normal exceptions.
Good luck,
Hani.
-Original Message-
From: Dariusz Wojtas [mailto:[EMAIL PROTECTED]]
Sent: Monday, March 04, 2002 1:01 PM
To: [EMAIL PROTECTED]
Subject: Handling exceptions
Almost every of my action classes has the try/catch block.
And I catch different types of exceptions that may be thrown
+ Throwable at the end
} catch ( ... ) {
log(...);
// add error;
} catch (Throwable t) {
log(...);
// add error
I found that in struts example apps, and in the struts source code,
there is always check for Throwable at the end.
But recently I was told that I should not use Throwable because it
is too high level, but Exception.
And now I am confused. May I use it or not?
Why does Struts use Throwable and not Exception?
Dariusz Wojtas
--
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]
RE: Handling exceptions
OK, that was helpful - now I see it from different perspective. But what if somebody argues that Throwable catches also JVM exceptions, like ThreadDeath or OutOfMemory and similar? Should I care about that or not? If not then why? Dariusz Wojtas At 13:14 02-03-04 -0500, you wrote: Catching Throwable will catch both Exceptions and Errors. Catching Exception will only catch Exceptions. You will want to catch Exceptions *AND* Errors to be bullet-proof. We were catching Exception for a while and we thought we were covered, until one day we got (due to some weird deployment) a NoClassDefFoundError, which of course escaped the catch Exception and barfed right in front of the user in their browser as an ugly 505. So I think catch Throwable should be your final catch-all after you have handled all your normal exceptions. Good luck, Hani. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: handling exceptions
We've developed a pretty eloborate exception handling framework on my current project. We're using EJB on the backend, so we must also deal with remote type exceptions. First we catorgize exceptions into those that the user can recover from and those that they can't. Sort of like fatal and non-fatal. You also need to divide exceptions into system and application exceptions. System exceptions are ones like remote exception, or maybe some type of datastore exception. Application exceptions for us are ones like required fields were missing or duplicate values for a unique column. In our world, the same exception framework has to work for ERP systems, so it's not just the web container. Anyway, for those exceptions that the user can recover from like required fields missing, we catch those type of exceptions, create an ActionError with a message from the bundle specifically for that exception, and then forward back to the input page. This gives the user a chance to fix the problem and resubmit. For the more severe exceptions, we also catch those and forward to a system-error type page since there's probably nothing you can do about it anyway. We use an abstract base action that all of our actions extend. We have all of this behavior in the base action and none of the action classes have to worry about catching these exceptions. The abstract base action implements the perform and has an abstract doWork type method. The doWork method is wrapped with the try catch blocks. Each concreate action class implements the doWork and doesn't have to worry about the try catch. I hope that gives you some ideas. chuck p.s. Regarding your other post about using System.out in your action classes; I wouldn't recommend that approach. Use log4j instead. That way, you can shut off the debug logging externally by just editing the log4j.properties file. At 09:50 AM 1/28/2002 -0200, you wrote: Could somebody help me ? I have to many problems with handling exception of the Struts. what do you suggest to handling exception of the deployment applications? -- 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]
RE: handling exceptions
How do you differentiate between these exceptions (throws, throw new, catch) in the JavaDocs? Mark -Original Message- From: Chuck Cavaness [mailto:[EMAIL PROTECTED]] Sent: Monday, January 28, 2002 7:27 AM To: Struts Users Mailing List Subject: Re: handling exceptions We've developed a pretty eloborate exception handling framework on my current project. We're using EJB on the backend, so -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Handling exceptions thrown from Action.perform in the errorpage?
global-forwards
forward name=errorpath=/errorpage.jsp/
/global-forwards
return mapping.findForward(error)
Will forward to the file named errorpage.jsp in the root of your Web
application.
If it doesn't, something else is wrong, like doPerform is not throwing
the exception (Try logging it too.), or the page is in the root of your
container instead, et cetera.
Meanwhile, when saving exceptions for display on a JSP, you might use
Action.EXCEPTION_KEY
for the attribute key. The custom tags use this, and so your page would
also display any exceptions the tags throw. (See saveException() in
util.RequestUtils)
[EMAIL PROTECTED] wrote:
Hey there!
I have a question for you guys.
When an exception is thrown in my Action derivative I want that exception
to
be handled by the errorpage (%@ page isErrorPage=true %). After fooling
around
with the web.xml file adding entries such as:
error-page
exception-typejavax.servlet.ServletException/exception-type
location/errorpage.jsp/location
/error-page
the result is that when I throw a ServletException from the Action.perform
method
I'm directed to my login page(?!). I've tried using the
mapping.findForward approach,
as in:
public final ActionForward perform(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
ActionForward af = null;
try {
af = doPerform(...); // throws exception
} catch(Throwable t) {
request.setAttribute(javax.servlet.jsp.jspException, new
ServletException(t));
af = mapping.findForward(error);
}
return af;
}
ofcourse, I added:
!-- == Global Forward Definitions
== --
global-forwards
forward name=errorpath=/errorpage.jsp/
/global-forwards
to the struts-config.xml file.
That didn't work either. The only approach that seems to work for me is:
public final ActionForward perform(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
{
try {
return doPerform(...); // throws exception
} catch(Throwable t) {
request.setAttribute(javax.servlet.jsp.jspException, t);
getServlet().getServletContext().getRequestDispatcher
(/errorpage.jsp).forward(request, response);
}
}
Now my questions are:
Is this last approach safe to use with Struts?
How do you guys accomplish this? Do you use a different approach
altogether?
TIA,
S. Bro
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
