dev@jsr311.java.net

Re: JSR311: Exception Handling

From: Marc Hadley <Marc.Hadley_at_Sun.COM>
Date: Sun, 06 Apr 2008 09:02:17 -0400

On Apr 4, 2008, at 6:50 PM, Stephan Koops wrote:
> • AFAIK it is not possible to get the generic class of the
> implementation of a generic interface. So how to get the exception
> type of a concrete ExcpetionMapper? Sorry, that this comes late. If
> I miss something, please let me know. (Java 5.0, not only 6.0)

Its a bit indirect but I think you can use reflection to find the
toResponse method of the mapper class and from that the type of the
exception parameter. That should be all you need.

>
> • Should the ExceptionMapper also be used, if a @*Param conversion
> throws an Exception and no Default is available? IMO not, because:
> • For problems while converting to @PathParam and @MatrixParam I
> think status 404 (not found) is the best: If the an URI part could
> not be converted (e.g. int as id required, but a unconvertable
> String was given), the resource does not exist. Because the
> ExceptionMapper doesn't really know the source of the exception, it
> could not react differentiated.
> • For problems while converting to @CookieParam, @HeaderParam and
> @QueryParam I prefer 400 (bad request).
> • IMO a special handling is only useful for
> WebApplciationExceptions (to be mapped as every
> WebApplicationException), but theoretical this is not allowed, but
> may occur.

I agree, dealing with @*Param conversions is something the runtime
should do directly. I didn't understand your last bullet point, could
you explain a bit more.
>
> • IMO it is useful to add also explicit to the javadoc
> ExceptionMapper.toResponse(.), that this method should not throw an
> WebApplicationException, because it is allowed at nearly all code
> point.

OK.

Marc.

---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.