注释类型 ExceptionHandler

@Target(METHOD)
@Retention(RUNTIME)
@Documented
public @interface ExceptionHandler

Annotation for handling exceptions in specific handler classes and/or handler methods. Provides consistent style between Servlet and Portlet environments, with the semantics adapting to the concrete environment.

Handler methods which are annotated with this annotation are allowed to have very flexible signatures. They may have parameters of the following types, in arbitrary order:

• An exception argument: declared as a general Exception or as a more specific exception. This also serves as a mapping hint if the annotation itself does not narrow the exception types through its value().
• Request and/or response objects (Servlet API or Portlet API). You may choose any specific request/response type, e.g. ServletRequest / HttpServletRequest or PortletRequest / ActionRequest / RenderRequest. Note that in the Portlet case, an explicitly declared action/render argument is also used for mapping specific request types onto a handler method (in case of no other information given that differentiates between action and render requests).
• Session object (Servlet API or Portlet API): either HttpSession or PortletSession. An argument of this type will enforce the presence of a corresponding session. As a consequence, such an argument will never be null. Note that session access may not be thread-safe, in particular in a Servlet environment: Consider switching the "synchronizeOnSession" flag to "true" if multiple requests are allowed to access a session concurrently.
• WebRequest or NativeWebRequest. Allows for generic request parameter access as well as request/session attribute access, without ties to the native Servlet/Portlet API.
• Locale for the current request locale (determined by the most specific locale resolver available, i.e. the configured LocaleResolver in a Servlet environment and the portal locale in a Portlet environment).
• InputStream / Reader for access to the request's content. This will be the raw InputStream/Reader as exposed by the Servlet/Portlet API.
• OutputStream / Writer for generating the response's content. This will be the raw OutputStream/Writer as exposed by the Servlet/Portlet API.
• Model as an alternative to returning a model map from the handler method. Note that the provided model is not pre-populated with regular model attributes and therefore always empty, as a convenience for preparing the model for an exception-specific view.

The following return types are supported for handler methods:

• A ModelAndView object (Servlet MVC or Portlet MVC).
• A Model object, with the view name implicitly determined through a RequestToViewNameTranslator.
• A Map object for exposing a model, with the view name implicitly determined through a RequestToViewNameTranslator.
• A View object.
• A String value which is interpreted as view name.
• @ResponseBody annotated methods (Servlet-only) to set the response content. The return value will be converted to the response stream using message converters.
• An HttpEntity<?> or ResponseEntity<?> object (Servlet-only) to set response headers and content. The ResponseEntity body will be converted and written to the response stream using message converters.
• void if the method handles the response itself (by writing the response content directly, declaring an argument of type ServletResponse / HttpServletResponse / RenderResponse for that purpose) or if the view name is supposed to be implicitly determined through a RequestToViewNameTranslator (not declaring a response argument in the handler method signature; only applicable in a Servlet environment).

In Servlet environments, you can combine the ExceptionHandler annotation with @ResponseStatus, to define the response status for the HTTP response.

Note: In Portlet environments, ExceptionHandler annotated methods will only be called during the render and resource phases - just like HandlerExceptionResolver beans would. Exceptions carried over from the action and event phases will be invoked during the render phase as well, with exception handler methods having to be present on the controller class that defines the applicable render method.