Struts' abnormal handling mechanism takes us very convenient. Through thinking and doing an example, I feel that the following way is more flexible:
First customize an exception class for your application. For example, first define a base class (can be a virtual class), note that it extends from RuntimeException, which is to capture smoothly in the Struts Action.
Public class baseexception extens runimeexception {...}
You can define a few subclasses, such as DAO abnormal, transaction exception, service exception, etc. In Spring, the package org.springframework.dao defines a set of DAO exceptions, which is worth learning.
Then, in the struts-cofig.xml file, the global exception is as follows, and the key attribute here is not ready:
public ActionForward execute (Exception exception, ExceptionConfig config, ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws ServletException {request.setAttribute ( "exception", exception); // return the original request Forward, of course, you can define a Global abnormal ForWord turns to it Return mapping.getinputForward ();}}
On the page (this page we are set to request an action, that is, the INPUT attribute of an exception, we can use the Struts tag as follows, note that the information and resource attribute files displayed here are not related to the information and resource attribute files. of:
Where is the benefits of this? Let's take a look, usually our ideas are logical errors. For example, the user name is repeated, or the data that is ready to modify has been deleted by others. We must capture it and display it to the user. The first thing is in action Made, for example: try {// do something logic method ...} catch (xxxexception e) {actionerrors errors = new actionerror (); actionerror error = new actionerror ("error.missing.username); errors.add ("Error.xxx", Error); SaveerRors (Request, Errors); Return mapping.findforward ("ErrorPage");} Good design is just a "road label director" in the web layer, the real logic method is Calling other business beans to complete, simply, the less the code in the action is, the better the code above. If the above global exception handling mechanism is used, Action can not be used in this case, and is responsible for the business bean. You can throw it, you can write less of the TRY CATCH in some action, or bypass the ActionError, is it clearer on the idea? Exceptions have been thrown in a true class, then transfer it up, and then to the action, Struts is responsible for capturing, of course, the exception here must have defined. Note: If you don't want to write myExceptionHandler class, of course, the handler = attribute in struts-config.xml also wants to remove, and one means to display the error message on the JSP page, first reference the JSTL tag library, then as follows:
2. If you feel that the error message is given to the programmer's free playing, or if you want to achieve internationalization, my idea is this, you can build an international resource file specialize in error messages, rules such as struts, using Spring ApplicationContext class To load, all the Server class passes the error code in this way, kEY, and get an error message. This is later.
