On Apr 1, 2008, at 9:27 AM, Bill Burke wrote:
> +1 on options 1-3.
>
> I'm conflicted on (iv) and (v).
>
> If we reword (v) to be any HTTP container with servlets as an
> example, then we don't need (iv).
>
Not sure I understand, are you saying we could do without
ContainerException ? The idea of introducing that is to standardize
the runtime exception that an implementation uses to wrap unhandled
(via the mechanism in (ii)) checked exceptions. Can you say a bit more
about how you'd reword (v) to get round (iv).
Marc.
> Marc Hadley wrote:
>> 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
>> ---
>> Marc Hadley <marc.hadley at sun.com>
>> CTO Office, Sun Microsystems.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
>> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.