On 18/02/12 11:41, Marek Potociar wrote:
>
>
> On 02/17/2012 04:55 PM, Sergey Beryozkin wrote:
>> Hi Marek,
>>
>> On 17/02/12 11:38, Marek Potociar wrote:
>>> Bill, Sergey,
>>>
>>> would you be able to work together on providing a concrete proposal for a JAX-RS exception hierarchy to start with? IT
>>> should cover both, client as well as server side. The goal would be to reuse the existing exceptions as much as possible
>>> as well as make the exception hierarchy common (for client and server), wherever it is practical.
>>>
>>
>> I think what you suggest is rather different to what I had in mind when starting the thread in the first place. I'd be
>> happy to work with Bill :-), but at the moment I'd prefer us focusing on a much smaller task, i.e, on making sure the
>> client code can get some reasonable support for figuring out:
>> - where the exception has occurred (client or server side)
>
> That's obvious from the response status code (if response is available), isn't it?
>
>> - more information about the server side exception
>
> Are you suggesting to standardize content of the responses with HTTP status code>= 400 ?
>
>>
>> To that end I've typed some comments, particularly I proposed introducing ClientWebAplicationException and
>> ServerWebApplicationException and work with these classes to make them useful.
>>
>> That is the base support, what do you think about that.
>>
>> As far as a finer grained hierarchy is concerned...
>> For now I'm not quite in favor of it.
>>
>> I can see why writing an ExceptionMapper<NotAcceptableException> is simpler than a custom
>> ExceptionMapper<WebApplicationException> and checking the status but I'm not convinced it can offer a complete 'cover'
>> for a user, instead of getting a single base ExceptionMapper<WebApplicationException> one would need to register
>> 5-7-maybe more mappers to cover all the possible HTTP errors the runtime may react to.
>
> Without any comments about fine vs. coarse gained exception hierarchies, what makes you think that one would NEED TO
> provide exception mappers for all exception types and not just one mapper for the base exception type?
>
>>
>> Exactly the same on the client side. With the finer grained hierarchy one would need to have a fairly big sequence of
>> catch blocks, with every individual exception basically offering an 'easy' interpretation of the HTTP error code.
>
> Again, why not just a single catch block for the base exception type? Additionally, since we would stick to extending
> from RuntimeException, there would be no mandatory catch block at all.
>
I haven't it would be 'mandatory'...
>>
>> I can't say I'm against the finer-grained hierarchy, rather I'm a bit cautious about introducing it at this stage, may
>> be for 2.1...
>
> I see. I guess what I am looking for is a concrete proposal with proper javadoc describing the exception hierarchy, that
> is potentially extensible and commonly reusable on server and client side. I did not try to imply the exception
> hierarchy proposal you come up with must be fine-grained. I'd leave that to your consideration and subsequent EG discussion.
>
>>
>> We'd have something like this for a start:
>>
>> BaseException (WebApplicationException ?)
>> | |
>> | |
>> ClientWebApplicationException ServerWebApplicationException (both: the client side)
>>
>> for a start.
>
> My initial feedback to those names would be that "client web application" sounds like an oxymoron and "server web
> application" sounds like a redundant definition. ;-)
>
>>
>> Possibly at the next stage, we can start with introducing some new finer exceptions directly off the BaseException and
>> get them reusable on both sides
>
> Ok, as I said, I am looking for a concrete, javadoc-ed proposal. The above is a good start for an internal conversation,
> but too fuzzy for including in the API yet.
>
Here is my proposal.
1. WebApplicationException serves as the base exception indicating that
a problem has occurred at the server side.
- this exception can be thrown on the server side by the runtime or the
application code
- this exception can be thrown on the client side by the runtime
processing the HTTP response containing a status code >= 400.
- this exception class can serve as the base for finer-grained
exceptions, example:
public class NotFoundException extends WebApplicationException {
public NotFoundException() {
super(404);
}
}
thus making NotFoundException/etc also catchable on the client side with
the code checking for WebApplicationExceptions...
2. Existing InvocationException gets removed
3. Existing ClientException gets the getResponse() method added.
4. As far as the client is concerned,
WebApplicationException and its possible subclasses would indicate that
the server response is a fault of some sort
5. ClientException will *only* indicate that the problem has occurred on
the client side. As suggested in 3 it will be nearly identical to the
existing ClientException but will have a getResponse() added.
Note that its getResponse() method will return 'null' for all the cases
except when the failure was caused by the client runtime unable to
process the server response (ex, no MBR was found).
Sergey
> Marek
>
>>
>> Thanks, Sergey
>>
>>> Let us know,
>>> Marek
>>>
>>> On 02/01/2012 03:46 PM, Bill Burke wrote:
>>>>
>>>>
>>>> On 2/1/12 9:40 AM, Santiago Pericas-Geertsen wrote:
>>>>>
>>>>> On Feb 1, 2012, at 9:15 AM, Bill Burke wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On 2/1/12 9:11 AM, Santiago Pericas-Geertsen wrote:
>>>>>>>
>>>>>>> On Jan 30, 2012, at 5:48 PM, Sergey Beryozkin wrote:
>>>>>>>
>>>>>>>>> MethodNotAllowedException
>>>>>>>>> BadRequestException
>>>>>>>>> NotAcceptableException
>>>>>>>>> InternalServerErrorException
>>>>>>>>> UnauthorizedException
>>>>>>>>> UnsupportedMediaTypeException
>>>>>>>>> NotFoundException
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Finally, these above exceptions would be useful on the server side.
>>>>>>>>> *NOT* for application code to catch, but rather to write
>>>>>>>>> ExceptionMappers for. So, Jersey/Resteasy whoever would throw those
>>>>>>>>> exceptions internally, and applications could write ExceptionMapper for
>>>>>>>>> those exceptions.
>>>>>>>>>
>>>>>>>>> Resteasy implemented these features on client/server after suggestions
>>>>>>>>> from users.
>>>>>>>
>>>>>>> I'm not sure I follow this. So the framework throws and catches the
>>>>>>> exception in order to call the user-defined mapper? Can you elaborate?
>>>>>>> This seems odd …
>>>>>>>
>>>>>>
>>>>>> I've had the case where users want to handle 404, 405, etc. on their own instead of the JAX-RS container handling
>>>>>> them automatically. This is especially the case where users want to send specific error formats back to the client.
>>>>>> That make sense more?
>>>>>>
>>>>>> Also, these exceptions might be thrown on the server side by app code too.
>>>>>
>>>>> I understand. In fact, the spec states that implementations should generate a WebApplicationException with the
>>>>> appropriate status code in all those cases (Section 3.7). So the use case should already be covered, but it's not as
>>>>> convenient as having an exception hierarchy?
>>>>>
>>>>
>>>> Exception hierarchy is nice, IMO. Especially on the client side.
>>>>
>>>> Bill
>>>>
>>
>>