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
otherwise.
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
Stephan