Hi Paul,
>> I do not see any advantage of the ContainerException. The runtime
>> environment could also handle exceptions directly. Let me know, what
>> I am missing.
> It is a standard way to wrap a checked exception and for it to be
> passed to the container, for example, consider this hypothetical example:
Yes, I know. For methods that are called directly (without the
reflection API, e.g. in Servlets), this is useful.
The reflection API will throw an InvocationalTargetException. We could
allow all exceptions thrown by the methods (as your example above
shows), which is not useful in APIs like the Servlet API. So we don't
need a special exception class IMO. If someone don't want this throws
clause, he could throw a WebApplicationException.
> @GET
> public byte[] get(@Param("charset") String charset)
> throws java.io.UnsupportedEncodingException {
> return "CONTENT".getBytes(charset);
> }
>
> how would the checked exception UnsupportedEncodingException be
> propagated and caught by the runtime and rethrown by the runtime to
> pass it to the container (if no exception provider is found for
> UnsupportedEncodingException) ?
IMO status 500. But every runtime environment could handle this as
internal "problem". Did I miss something?
>> 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.
> The processing of wrapped IOException and ServletException are
> specific only to the JAX-RS servlet container.
>
> If the Servlet container catches the runtime ContainerException and
> the wrapped exception is either IOException or ServletException then
> it re-throws the wrapped exception otherwise it re-throws the
> ContainerException.
If it is only internal, than it is ok. My point was to not throw
ServletExceptions in the JAX-RS resource methods.
> The thinking behind this was that developers may want to transition
> some servlet code to JAX-RS code but still may need to call other
> "legacy" functionality (that throws IOException and/or
> ServletException) and they want to retain the same behavior when
> exceptions are thrown.
IMO it is not useful. - But if we allow all exceptions to be thrown and
the runtime handles it as 500 or by ExceptionMapper, than a Servlet
runtime environment could handle ServletExceptions in a special way and
propagate it to the Servlet.
Stephan