Hi Andrew,
A NPE is definitely a bug (internal server error) so, separately from
the exception mappers, we should try and work out why that is happening.
The spec states:
https://jsr311.dev.java.net/nonav/releases/1.0/spec/index.html
A MessageBodyWriter.write method MAY throw WebApplicationException.
If thrown before the response is committed, the
exception is treated as if it originated from a resource method,
see section 3.3.4. To avoid an infinite loop, implementations
SHOULD NOT attempt to map exceptions thrown during serialization of
an response previously mapped from an exception
and SHOULD instead simply return a server error (status code 500)
response.
The code to map exceptions when writing is (see
com.sun.jersey.server.impl.application.WebApplicationImpl):
try {
response.write();
} catch (WebApplicationException e) {
if (response.isCommitted()) {
throw e;
} else {
mapWebApplicationException(e, response);
response.write();
}
}
So for the case when the response is already committed (some bytes
were written to the output stream) or a runtime exception other than
WebApplicationException is thrown then the exception is propagated to
the HTTP container.
The spec does not state what to do in the case of a runtime exception
other than WebApplicationException is thrown before a response is
committed.
Paul.
On Apr 27, 2009, at 11:43 PM, Andrew Ochsner wrote:
> Actually it could even be that all NPE don't get mapped by the
> ExceptionMapper<Throwable> Would that make sense?
>
> On Mon, Apr 27, 2009 at 1:50 PM, Andrew Ochsner <aochsner_at_cs.stanford.edu
> > wrote:
> Hello:
>
> I am noticing that when there is an exception in the Jersey
> framework code, specifically when marshalling json into an object
> (via jaxb) throws a NullPointerException, that the exception mappers
> never get called to convert that exception into a proper response.
> I have an exception mapper that maps all Throwable exceptions into
> 500 errors but it only passes the exception.getMessage() in the body
> rather than the full stack trace. In these exceptions I'm seeing
> the full stack traces which is leading my down this thinking.
>
> I scanned the jsr311 and it states:
> When a resource class or provider method throws an exception, the
> JAX-RS runtime will attempt to map the exception to a suitable HTTP
> response - see section 3.3.4. An application can supply exception
> mapping providers to customize this mapping.
>
> To me that sounds like when a provider (in this case the jaxbjson
> marshaller using natural) throws an exception, that Jersey should be
> mapping that via the exception mappers.
>
> I can probably write a quick unit test to try to replicate this, but
> just thought I'd throw it on the mailing list to see if I'm
> completely wrong first.
>
> Thanks again
> Andy O
>