Re: JSR311: Exception Handling

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Tue, 01 Apr 2008 15:20:13 +0200

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

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.

> 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?


> Perhaps we talked cross-purposes.

Quite possibly!


| ? + ? = To question
    Paul Sandoz