> On Oct 10, 2008, at 11:40 AM, cowwoc wrote:
>>
>> I'd like to process all uncaught RuntimeExceptions thrown by
>> resource methods. I'm simply trying to ensure that resource methods
>> returns a valid response even if the code forgets to catch an
>> exception. Now, I could add try{}catch blocks on a per-method basis
>> one by one but it seems like there should be a better mechanism for
>> doing this that is easier to maintain.
>
> That's what ExceptionMapper is designed to do. I don't understand
> which exceptions you want to exclude however ? An example might be
> useful.
>
> Thanks,
> Marc.
>
Hi Marc,
Under Jersey, ExceptionMapper<RuntimeException> gets called even for
Jersey internal exceptions, such as
*com.sun.jersey.api.container.ContainerException. 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 :(
*Gili
*