Re: JSR311: Exception Handling

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Tue, 01 Apr 2008 10:06:52 -0400

On Apr 1, 2008, at 9:20 AM, Paul Sandoz wrote:
> Stephan Koops wrote:
>>> In Jersey we originally trapped all exceptions and converted then
>>> to 500 responses. But some developers said it was too restrictive,
>>> and requested that exceptions be propagated to the web container
>>> so they could configure error pages.
>> ok, this make sense.
>> What about allow all exceptions (checked an unchecked) on resource
>> methods anc sub resource locatores and let the JAX-RS runtime do
>> "what it want"? Than we don't need a new standard exception for
>> this. A Servlet implementation can propagate the exceptions to the
>> Servlet and use the web.xml, another implementation could use their
>> own mechanisms convert to status 500.
> But the disadvantage would be such behavior is no longer portable:
> in some web containers the error pages work and in others they would
> not. I would prefer to have consistent standardized behavior
> (whatever the solution).
> The only reason to have a standardized runtime exception that wraps
> the targeted checked exception is so that the container knows what
> type of exception it is independent of a JAX-RS implementation. It
> seems such a small thing to create a new type for, so i can
> understand the objection. An alternative is that the JAX-RS runtime
> never propagates a targeted checked exception, wrapped in a runtime
> exception, to the container (modulo the servlet-based exceptions
> still under discussion). If there is no provider for a targeted
> checked exception the JAX-RS runtime returns a 500 response.
That's a possibility but note that with the proposal its really easy
for an application to map any exception to 500:

public class ExceptionBackstop implements ExceptionMapper<Exception> {
  boolean isMappable(Class<E> type) {return true;} // still not sure
we need this method
  Response map(E exception) {return Response.serverError().build();}

>> This could also be combined with the ExceptionMapper. I think it is
>> a good possibility to allow special responses for special exceptions.
>> Stephan
>> P.S.: Paul: Do we need the ContainerException when using this way?
> No.
For portability I think we need defined behavior for checked
exceptions thrown within a Servlet-based or SE-based implementation.
Is the concern that we don't want to restrict what implementations do
in other types of container ? I'd be happy to craft the language to
support other exception handling mechanisms, I don't want to overly
restrict things, just ensure portability for the containers we
explicitly target.


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