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:
@Provider
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.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.