Stephan Koops wrote:
> 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.
Not sure i understand you. I was referring to propagating the targeted
(checked or otherwise) exception (thrown from a constructor, resource
method or sub-resource locator directly or indirectly) in a *standard
specified* way to the container.
> 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?
Some people use the error page functionality in the web.xml with runtime
exceptions. To support this it is necessary that runtime exceptions be
propagated in a standard way to the web container rather than being
caught by the JAX-RS runtime.
In Jersey we originally trapped all exceptions and converted then to 500
responses. But some developers said it was too restrictive, and
requested that exceptions be propagated to the web container so they
could configure error pages.
Paul.
>>> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109