Marc Hadley wrote:
> On Mar 10, 2008, at 7:01 PM, Reto Bachmann-Gmür wrote:
>
>> After reading the editors Note 2.1 (in section 2.2.3 of the january
>> 31 draft) I was wondering why there isn't a mechanism to convert
>> types of (checked) exceptions to to WebApplicationsException (similar
>> to the conversion of java-objects to message bodies).
>>
>> A use case would be various resource methods invoking methods on a
>> backend-proxy which may throw BackendOverloadedExceptionS, instead
>> that all resource methods catch this exception and throw a
>> WebApplicationException with a explanatory response body, a single
>> converter for BackendOverloadedException would be registered and the
>> resource methods would just propagate the checked Exception.
>>
> To paraphrase you're saying we could treat the exception just like a
> method return value and support the ability to have a provider handle
> conversion to a HTTP response. Have to think about that some more but
> it sounds like an interesting idea.
The difference is that while a non-null method return value leads to a
200 response, for exceptions different 4XX or 5XX may be appropriate.
So exceptions should be converted either to a WebApplicationException or
to a Response and not just to an entity body. I suggest doing the
conversion to WebApplcationException allowing converters to generate a
whole Response or to just enforce a response status.
So I suggest the following exception handling:
1. WebApplicationException -> catched and mapped to a response by
implementation (same as current draft)
2. Runtime Exception -> propagated to the conatiner (same as current
draft)
3. Checked Exceptions -> converted to WebApplicationException using
the most specific ExceptionConverter, the fall back exception
converter converts to a new WebApplicatinsException(500, cause) ->
The WebApplicationException is the handled as if thrown by a
resource method.
Reto