Paul Sandoz wrote:
> Hi,
>
> The Jersey supplied message body readers throw WebApplicationException
> which then thrown causes the client side to throw a null pointer
> exception when the jersey-server module is not present. This is
> because a Response.ResponseBuilder implementation does not exist.
>
Isn't this exception caught by logic inside the client infrastructure,
where we could do the right thing with it? Or am I not understanding
the entire scenario?
> I think the right solution is for such readers to throw a
> MessageBodyReaderException runtime exception which is then mapped on
> the server side to a 400 client error response. Thus such an exception
> on the client sid makes sense to the developer rather than reusing
> WebApplicationException with dummy-based response builder.
Would MessageBodyReaderException be a subclass of
WebApplicationException? That would be consistent with the spirit of
what the spec says about providers -- they MAY throw
WebApplicationException or IOException from the readFrom() method, but
it's silent about any others.
On the server side, shouldn't this be mapped to a 500, not a 400? It
doesn't seem like the client's fault if the server accepted a request,
but then had trouble parsing it because of a missing dependency or
something.
Craig
>
> This should apply to all the readers in core, atom, multipart etc that
> are capable of detecting client errors.
>
> What do others think?
>
> Paul.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>