dev@jsr311.java.net

Re: JSR311: Exception Handling

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Fri, 04 Apr 2008 13:53:57 -0400

While adding this to the spec I made a few changes and eliminated the
need for ContainerException. Here's what I put into the spec:

(i) Allow resource methods to throw any checked or unchecked exception

(ii) Define a new ExceptionMapper provider type. An application can
define implementations of this interface to convert any runtime or
checked exception to a Response that will then be processed as if the
method returned the response directly. Implementations will catch all
exceptions and look for a provider that will handle the exception. If
one is found it is used to create a response, if not the
implementation rethrows the exception, see (iv).

(iii) Define provider marching such that the closest matching
exception mapper (by inheritance hierarchy) is used. Thus if an
application provides ExceptionMapper<Exception> and
ExceptionMapper<RuntimeException> and the application throws
IndexOutOfBoundsException then the implementation of
ExceptionMapper<RuntimeException> will be used.

(iv) Unmapped runtime exceptions are re-thrown directly. A servlet-
based impl has to wrap unmapped checked exceptions (except
ServletException) in a new ServletException. A JAX-WS Provider-based
impl has to wrap unmapped checked exceptions (except
WebServiceException) in a new WebServiceException. Implementations for
other types of container have to define their own handling for
unmapped checked exceptions.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.