Hi all,
IMO all not specially handled Exceptions (checked and RuntimeExc) should
result in status 500. The ExceptionMapper is useful, to allow special
handling for special exception classes. IMO the runtime environment
should warn, if it found resource methods with declared exceptions
(RuntimeExc AND non-runtime exceptions, excluding
WebApplicationException), for which no corresponding ExceptionMapper is
available. But if folks don't want this, every container could do this
for its own.
I do not see any advantage of the ContainerException. The runtime
environment could also handle exceptions directly. Let me know, what I
am missing.
IOExceptions should not especially allowed, IMO: IOExc are allowed in
Servlets (e.g.), because they could occur while writing to the network
OutputStream, and there is no usefull handling possible. By contrast
JAX-RS resource methods have no access to the OutputStream, so
IOExceptions could not be thrown from this OutputStream. (The
StreamingOutput allows throwing IOExc, but this is outside of the
resource method.) All other IOExceptions (resulting from reading data
for the resource) should be converted to (or wrapped into) to a
reasonable, meaningful WebApplicationException IMO. (responsibility of
app develpers)
IMO it is also not useful to allow ServletExceptions. It creates a
dependency to Servlets, and I see no advantage for this. Where is it
useful, to throw an ServletException, without wrapping Exceptions in a
Servlet method? Let me know.
best regards
Stephan
Marc Hadley schrieb:
> Issue 26[1] concerns exception handling. Currently the only exception
> handled by a JAX-RS runtime is our own WebApplicationException, any
> RuntimeException is propagated to the container, and we don't say what
> should happen if a resource method declares checked exceptions (see
> ednote 3.1 in the latest spec draft). Here's a proposal for addressing
> this:
>
> (i) Allow resource methods to declare checked exceptions
>
> (ii) Define a new provider type along the following lines:
>
> public interface ExceptionMapper<E extends Exception> {
>
> boolean isMappable(Class<E> type); // not sure if we really need this
>
> Response map(E exception);
> }
>
> An application can define implementations of this interface to convert
> any runtime or checked exception to a Response that will then be
> processed in the usual way. Implementations will catch all exceptions
> and look for a provider that will handle the exception. If one is
> found it is used to create a response, if not the implementation
> rethrows the exception, see (iv).
>
> (iii) Define provider ordering such that the closest matching
> exception mapper (by inheritance hierarchy) is used. Thus if an
> application provides ExceptionMapper<Exception> and
> ExceptionMapper<RuntimeException> and the application throws
> IndexOutOfBoundsException then the implementation of
> ExceptionMapper<RuntimeException> will be used.
>
> (iv) Define a new RuntimeException: ContainerException. An application
> can throw this exception directly to have the exception propagate to
> the container. An implementation will use this to wrap checked
> exceptions thrown by a resource method and not handled by an exception
> mapper provider. Runtime exceptions not handled by an exception mapper
> provider will be rethrown directly.
>
> (v) Define deviations to (iv) for servlet container. An servlet-based
> implementation won't wrap ServletException or IOException since these
> can be thrown directly.
>
> Thoughts, comments ?
> Marc.
>
> [1] https://jsr311.dev.java.net/issues/show_bug.cgi?id=26