Re: JSR311: Exception Handling

From: Stephan Koops <>
Date: Tue, 01 Apr 2008 15:36:54 +0200

Hi Paul,
> But the disadvantage would be such behavior is no longer portable: in
> some web containers the error pages work and in others they would not.
> I would prefer to have consistent standardized behavior (whatever the
> solution).
Then you can not use the behaviour of web.xml for exceptions or any
features of the underlying container.
> The only reason to have a standardized runtime exception that wraps
> the targeted checked exception is so that the container knows what
> type of exception it is independent of a JAX-RS implementation. It
> seems such a small thing to create a new type for, so i can understand
> the objection. An alternative is that the JAX-RS runtime never
> propagates a targeted checked exception, wrapped in a runtime
> exception, to the container (modulo the servlet-based exceptions still
> under discussion). If there is no provider for a targeted checked
> exception the JAX-RS runtime returns a 500 response.
ok, than let's use the ExceptionMapper.

I think we should give also the MediaType to the extension mapper. So it
could create an HTML page for browsers and e.g. a plain text message
The method isMappable could perhaps return, if it

   1. supports the exception class and the MediaType (best)
   2. supports only the exception class, but with a different media type
   3. does not support the class.

Than we could use Boolean as return type defining null for (2), or int
[(1): >= 0; (2): == 0; (3): <= 0]. We should not define -1 and 1 as
default, but -10 and 10 or something like taht to allow ExceptionMappers
to be placed between default (1) and zero for special cases.

public interface ExceptionMapper<E extends Exception> {
    boolean isMappable(Class<E> type, MediaType);
    Response map(E exception, MediaType);

best regards