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.
> 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.
> Perhaps we talked cross-purposes.
>
Quite possibly!
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109