Hi Paul,
>> 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.
ok, this make sense.
What about allow all exceptions (checked an unchecked) on resource
methods anc sub resource locatores and let the JAX-RS runtime do "what
it want"? Than we don't need a new standard exception for this. A
Servlet implementation can propagate the exceptions to the Servlet and
use the web.xml, another implementation could use their own mechanisms
convert to status 500.
This could also be combined with the ExceptionMapper. I think it is a
good possibility to allow special responses for special exceptions.
Stephan
P.S.: Paul: Do we need the ContainerException when using this way?
Perhaps we talked cross-purposes.