Okay, If you want to handle where to go next in one place then create the abstract class and have All the exception handling extends from it. All the handler action need to do is to do profiling Of the exception, and the abstract class's perform(...) will catch the exceptions handle it or Just forward it to the associated VIEW. This works too, if you want all of your action Extends from this abstract action, if this is the case you want, which I would prefer, then You might want your abstract class to handle the exception, meaning you want the abstract class To catch it, profile/log the exception and then forwad to the VIEW. If this is the case then Your exception handler action doesn't have to do anything but throw the correct exception so the Abstract action class will catch it and handle it for you.
If you are looking at this clearly, what we want to do is to create a template of execution at The base of all your application exceptions to handle different kind of exceptions. And since We can only do this if exception being throw inside of the execution context of a dispatched Action class, exceptions that might happen in the VIEW, the original problem that init our Conversation, will not get handled. And so if we want it to be control in one place then what Should we do? Ahah.. We use the web.xml exception mapping to do the work. Meaning, we use The web.xml exception mapping to map all the exceptions that happen outside of the Action's Execution context back into an Action mapping with in turns will re throw it so that the Exception is now within the Action's execution context. There is many different way to do This, and it all depends on the need of your application. This just an idea or should I say Concept of how to handle exceptions and errors within a web application. If you implement this with Struts and Tiles, then is no need for using the conventional JSP's Page directive to handle error. There is a few reasons why I don't like this is error handling Logic are coupling with JSPs every where and it is hard to manage and reuse. Where as if you Follow my approach, you can pretty much go to one or two place to see how all the error being Handled, and if you decided to reuse it all that is need to do is to modify your strusts-config.xml, Web.xml and Wala... You have it up runing. Let me know if anything else I can help you with ... :) --danny Ps. Don't know how advance this technique is, but I do hope that Chuck Struts book, and Ted/Credic/..'s Struts book mention about best practice of handling erro and exception within web application. -----Original Message----- From: atta ur-rehman [mailto:[EMAIL PROTECTED]] Sent: Monday, November 18, 2002 1:22 PM To: Struts Users Mailing List Subject: Re: Howto handle this behavior in Struts+Tiles Hi Danny, I'm confused already!!! here is the abstract action class with an abstract execute method: --------------------------------------------------------------------------- import javax.servlet.http.*; import org.apache.struts.action.*; public abstract class AbstractErrorHandlerAction extends Action { public abstract void execute(ActionMapping mapping, ActionForm form, HttpServletRequest request , HttpServletResponse response) throws Exception; } --------------------------------------------------------------------------- now should all my actions extend this class? or its only the action handler action that would extend this class? moreover, I don't see throws clause in the perform(...) method of Action class? So, am I completely lost? I hope you won't mind my simplistic questions!!! ATTA ----- Original Message ----- From: "Trieu, Danny" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Monday, November 18, 2002 1:05 PM Subject: RE: Howto handle this behavior in Struts+Tiles > I thinks so ... > > Good luck...:) > > --danny > > -----Original Message----- > From: atta ur-rehman [mailto:[EMAIL PROTECTED]] > Sent: Monday, November 18, 2002 1:05 PM > To: Struts Users Mailing List > Subject: Re: Howto handle this behavior in Struts+Tiles > > > okay, let me give it a try and I'll get back to you! thanks. > > by the way, do you if this feature is available thru servlet 2.2 > specs? > > ATTA > > > ----- Original Message ----- > From: "Trieu, Danny" <[EMAIL PROTECTED]> > To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> > Sent: Monday, November 18, 2002 11:54 AM > Subject: RE: Howto handle this behavior in Struts+Tiles > > > > You are almost close ... :) Yes my point 3 is that mapping in the > > web.xml. But Instead of going to the JSP, > > <location>/ErrorPage.jsp</location>, you > would > > want > > To go to <location>/errors/catchError.do</location>, which map it to > > a Action that You extended from your abstract action class. This > > action would do all > the > > necessary > > Stuff with your Exception if there is one or create a new exception > > and throw it. > > > > --danny > > > > -----Original Message----- > > From: atta ur-rehman [mailto:[EMAIL PROTECTED]] > > Sent: Monday, November 18, 2002 11:42 AM > > To: Struts Users Mailing List > > Subject: Re: Howto handle this behavior in Struts+Tiles > > > > > > Hi, > > > > This definitely is helpful. As I'm not very experiences in Struts, > > does > your > > point 3 refers to > > > > <error-page> > > <exception-type>java.lang.Exception</exception-type> > > <location>/ErrorPage.jsp</location> > > </error-page> > > > > construct in "web.xml" or is it something different? If its the same > thing, > > how do I know if my JSP container supports this feature or not. I'm > > asking this because we are running ServletExec 3.1 that is compliant > > to Servlet > 2.2 > > only. > > > > Thanks. > > > > ATTA > > > > > > ----- Original Message ----- > > From: "Trieu, Danny" <[EMAIL PROTECTED]> > > To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> > > Sent: Monday, November 18, 2002 11:15 AM > > Subject: RE: Howto handle this behavior in Struts+Tiles > > > > > > > Hello, > > > > > > 1.0 doesn't support declarative exception handling, but it doesn't > > > prevent you from Doing so...:) Anyway, what I would do is: 1) > > > Implement an abstract Action have and Abstract method execute(...) > > > throw Exception. 2) Implement the > > perform(...) > > > method > > > That will call you're the abstract excecute(...) method, and catch > > > all or any specific Exception and return the associated forward to > > > the specific View(JSP) as needed. > > > 3) Map all/any error-code and exception mapping in your web.xml to > > > an > > Action > > > that > > > Extended from your abstract exception. This exception can be > > > generic or specific to A particular mapping, it will profile the > > > exception and re-throw or create > > a > > > new exception > > > And throw it, so that the perform method will catch this exception > > > and > > route > > > it to the > > > Targeted VIEW. > > > > > > Hope this would help, > > > > > > --danny > > > > > > -----Original Message----- > > > From: atta ur-rehman [mailto:[EMAIL PROTECTED]] > > > Sent: Monday, November 18, 2002 10:57 AM > > > To: Struts Users Mailing List > > > Subject: Re: Howto handle this behavior in Struts+Tiles > > > > > > > > > Thanks, Danny, for the detailed response. > > > We're running Struts 1.0.x. Does it support ExceptionHandler > > > paradigm? If > > so > > > could you please point towards some starting points. > > > > > > Thanks again. > > > > > > ATTA > > > > > > > > > ----- Original Message ----- > > > From: "Trieu, Danny" <[EMAIL PROTECTED]> > > > To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> > > > Cc: "Mebed, Waheed" <[EMAIL PROTECTED]> > > > Sent: Monday, November 18, 2002 10:36 AM > > > Subject: RE: Howto handle this behavior in Struts+Tiles > > > > > > > > > > Hello, > > > > > > > > Usually exception that being thrown by the VIEW(JSP) are > > > > rendering related exception. This could be tags/Scriptlet that > > > > access resource, JavaBeans, fails. Meaning the Resource is not > > > > there. And when these thing happen with composite view thing > > > > became A bit tricky. First of all, within the container, the > > > > layout, of the composite view You don't where exception might be > > > > thrown. Second, the page directive > > for > > > > 'errorPage' > > > > Can only be set at the outter most container, the layou, and not > > > > within > > > any > > > > of its > > > > Contained JSP. Since, you never know when response has been > > > > committed to the client Browser. And if response has already > > > > committed to the clien browser, any attemp to Forward to a > > > > different resource is an IllegalStateException. A quick > > > > solution to your Problem is to only have the page directive for > > > > your JSP is in the > outer > > > most > > > > container, > > > > The layout. > > > > > > > > My approach to handling the front-end exception in Struts1+ is > > > > having a sub-module for Handling exception with a set of custom > > > > or generic ExceptionHandler, with action mapping That will > > > > capture the exception, do exception profiling or anything > > > > neccessarry, and use Struts declarative exception handling to > > > > map it to a user friendly > View > > > for > > > > displaying > > > > Specific error pages. This has to work with the Web application > > > > error mapping in the Web.xml deployment descriptor, to map > > > > different error-code and exception > > > to > > > > the right > > > > Action mapping in your exception sub-module that will handle the > > > exception. > > > > I think > > > > This is a much cleaner way to haddle exception since it promote > > > > encapsulation of exception Handling into one central place, the > > > > sub-module, that can be manage easily and consistent Through out > > > > the entire application. Plus, exception handler can be > > reused > > > > in different > > > > Web application with the entire enterprise. > > > > > > > > Hope this would help, > > > > > > > > -danny > > > > > > > > -----Original Message----- > > > > From: atta ur-rehman [mailto:[EMAIL PROTECTED]] > > > > Sent: Monday, November 18, 2002 9:52 AM > > > > To: struts users mailing list > > > > Subject: Howto handle this behavior in Struts+Tiles > > > > > > > > > > > > Dear all, > > > > > > > > Here is my "layout.jsp" file: > > > > > > > > <%@ page errorPage="ErrorPage.jsp" %> > > > > > > > > <tiles:insert attribute="menu"/> > > > > <tiles:insert attribute="body"/> > > > > <tiles:insert attribute="footer"/> > > > > > > > > The "menu" tile is a JSP page that could throw an exception. Now > > > > whenever > > > an > > > > exception is thrown on the "menu" tile I want to goto JSP Error > > > > Page. What > > > I > > > > get instead is this exception: > > > > > > > > [Exception in:/main-menu.jsp] reset() failed - data has already > > > > been sent > > > to > > > > client java.lang.IllegalStateException: reset() failed - data > > > > has already been sent to client. > > > > > > > > Could you please help me with this one? What do I need to fix > > > > this > > > problem. > > > > By the way "menu.jsp" contains <%@ page > > > > errorPage="ErrorPage.jsp" %> directive. And currently if there > > > > is an exception on "layout.jsp" Error > > > Page > > > > does show up with appropriate error message. > > > > > > > > TIA, > > > > > > > > ATTA > > > > > > > > > > > > -- > > > > 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]> > > > > > > -- > > > 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]> > > > > -- > > 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]> > > -- > 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
