Clarification / TCK about ResponseExceptionMapper returning NULL

[svenhaag]

From Spec 2.0 about how to implement a ResponsExceptionMapper, it seems possible to implement an exception mapper that returns null for e.g. HTTP 503.

1. If I understand correctly, this should not throw a WebApplicationException in such a case?
2. What should happen if the DefaultExceptionMapper is disabled?

I think the TCK is missing at least the second corner case.

They fixed the second case in RestEasy, but I think this should be covered in the TCK too.

https://issues.redhat.com/browse/RESTEASY-2882
resteasy/resteasy#2850

[andymc12]

Hi @svenefftinge - sorry for the long delay in responding, and thanks for bringing this up. It's a good question!

I think the scenario could be more broad, and could even occur for normal responses. For example, suppose your client interface method expects a return type of Integer, but the server returns a 200 OK response with a floating point number as the HTTP entity. It's not an exception, but the return type is different. I imagine some vendors will throw a ClassCastException in that case, but I think that a JAX-RS ResponseProcessingException (perhaps with a CCE as the cause) is more appropriate.

In the case where there is an error response code (like 503) but no response exception mappers voting to handle it, I think we should first consider whether there is still an entity that could be converted to the response type in the interface method. A user might have a RealObjectOrErrorResponse type that would process the error data in the HTTP response. In that case, it should be business as usual - just convert the entity and return it. Alternatively, a user might have a RealObject type, but the HTTP response contains error info - that won't be converted to a RealObject. In that case, I lean toward the Rest Client implementation throwing ResponseProcessingException. Another scenario is what happens when no entity is present at all, but the client is expecting one (this could occur with 204 responses just as easily as 4XX and 5XX responses). We could either return null or throw an exception. Again, I lean toward throwing a ResponseProcessingException because it is consistent with the language in JAX-RS Response#readEntity method:

Returns:
the message entity; for a zero-length response entities returns a corresponding Java object that represents zero-length data. In case no zero-length representation is defined for the Java type, a ProcessingException wrapping the underlying NoContentException is thrown.
...
ProcessingException - if the content of the message cannot be mapped to an entity of the requested type.

Note that ResponseProcessingException is a subclass of ProcessingException.

So, something like this (all assumes that there is no ResponseExceptionMapper that converts to the requested entity type):

Response Code	HTTP Entity	Client Interface Method Return Type	Behavior
Any	Widget	Widget	return as normal
204, 503, ...	empty	Widget	ResponseProcessingException (wrapping NoContentException)
4XX, 5XX	empty	Widget	ResponseProcessingException
4XX, 5XX	Error	Widget	ResponseProcessingException
4XX, 5XX	Error	WidgetOrError	return as normal - assuming MBR can convert

What do you think about this approach?