On Oct 13, 2008, at 12:07 PM, cowwoc wrote:
>
> Under Jersey, ExceptionMapper<RuntimeException> gets called even
> for Jersey internal exceptions, such as
> *com.sun.jersey.api.container.ContainerException.
Does the stack trace include a resource or provider method ? I'm
wondering about the origin of the exception. You should only be seeing
exceptions that originate in the context of a resource or provider
method or in the creation of a resource method parameter, field or
property value.
> Now it could very well be a case where someone wants to intercept a
> ContainerException, but I don't, and there is no way for me to tell
> Jersey to propagate this exception up to the container as it
> originally planned to. A similar use-case is when
> **com.sun.jersey.api.ConflictException or
> **com.sun.jersey.api.NotFoundException get thrown. In such a case
> you might want to intercept it and return a custom Response, but you
> might not. At least in such a case both exceptions extend
> *javax.ws.rs.WebApplicationException so you can simply return
> exception.getResponse().
>
> I'm expecting ExceptionMapper to apply the chain-of-responsibility
> design pattern: http://en.wikipedia.org/wiki/Chain-of-responsibility_pattern
> ... if no ExceptionMapper ends up handling the exception it should
> then fall on the underlying implementation to figure out how to
> convert it to a Response. I was a disappointed to read that when
> ExceptionMapper.toResponse() returns null it gets mapped to |
> Response.Status.NO_CONTENT| <https://jsr311.dev.java.net/nonav/releases/1.0/javax/ws/rs/core/Response.Status.html#NO_CONTENT
> >. What you could have done instead is mapped null to "I didn't
> handle the exception" and let developers return a Response object
> for |Response.Status.NO_CONTENT| <https://jsr311.dev.java.net/nonav/releases/1.0/javax/ws/rs/core/Response.Status.html#NO_CONTENT
> >.
>
> Does the maintenance release of JAX-RS allow you to break
> backwards compatibility by modifying the meaning of the return code,
> adding interface methods or throwing new exceptions? Otherwise I'm
> not exactly sure how you're going to be able to solve this :(
>
There are a couple of things we could look at like adding an exception
to indicate that the ex wasn't handled or adding an ExceptionMapper2
interface but neither is particularly appealing. I'd like to get to
bottom of where the exceptions are coming from before we think about
that.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.