On Oct 13, 2008, at 7:15 PM, Marc Hadley wrote:
> 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.
>
I think there is a bug in Jersey it does not differentiate based on
where the exception originates.
Paul.
>> 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.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: users-help_at_jsr311.dev.java.net
>