jsr339-experts@jax-rs-spec.java.net

[jsr339-experts] Re: [jax-rs-spec users] Re: Re: Re: Re: Re: Re: Re: Re: Concerns about the client-side exception hierarchy

From: Santiago Pericas-Geertsen <Santiago.PericasGeertsen_at_oracle.com>
Date: Thu, 29 Mar 2012 10:26:53 -0400

Marek, Sergey,

 Generally speaking, I like the idea of sharing and having fewer classes. However, when you look at the details (like WAE) the server-centric style of JAX-RS 1.X keeps popping up :( We sort of concluded the same for Request, Response, filters, etc.

 It seems almost inevitable that we'll end up arriving at the same conclusion for exceptions. If that's the case, I think we should only define new exceptions for the most common error conditions (should only be a few) and leave the general case to WAE (and its client counterpart).

-- Santiago

On Mar 29, 2012, at 8:13 AM, Marek Potociar wrote:

>
> On Mar 29, 2012, at 11:09 AM, Sergey Beryozkin wrote:
>
>> By the way,
>> On 28/03/12 22:19, Sergey Beryozkin wrote:
>>> Hi Marek
>>> On 28/03/12 19:02, Marek Potociar wrote:
>>>> Hi Sergey,
>>>> What you write makes sense and I see the thought behind your proposal.
>>>> If we manage to keep a single Response class for server and client side,
>>>> I am ready to support the proposal.
>>>>
>>>> If we however currently consider having separate ClientResponse on the
>>>> client side, I would rather see it as an interface not extending the
>>>> core.Response. And as such, I don't like WAE being visible to the
>>>> application layer on the client side (since it contains a non-null
>>>> Response instance and a getter for it).
>>>>
>>>> To explain, why I prefer to not extend the Response in the
>>>> ClientResponse:
>>>>
>>>> 1. it does not bring almost any improvements over the current common
>>>> response API and keeps most of the issues that need to be resolved
>>>> by fine-grained method javadoc-ing.
>>>> 2. it does not solve the WAE issue with the contained server-side
>>>> Response on the client side - asking users to cast or convert the
>>>> WAE response to a ClientResponse is to me very user unfriendly and
>>>> looks like a desperate design solution.
>>>>
>>> Right...
>>>>
>>>> So right now it seems to me that concrete exceptions for particular
>>>> error codes should not be common for client and server. IOW, something
>>>> like this:
>>>>
>>>> ServerErrorException
>>>> - WAE
>>>> - BadRequestException
>>>> - ...
>>>> - ClientBadRequestException
>>>> - ...
>>>>
>>>> Alternatively, we can still consider keeping the common Response for
>>>> client and server...
>>> If it were possible to achieve then it would be good, not sure it would
>>> be :-)
>>>>
>>> IMHO having a number of exception classes able to represent the same
>>> error code will be problematic. I can see 3 at least in the example for
>>> the status 400 :-).
>>>
>> That is not a very good argument. I think the better one is that we can have a case where the server application acts as a client, so effectively we can have a single chunk of code where BadRequestException is thrown and ClientBadRequestException is caught, ex:
>>
>> @Path("/")
>> public class RootResource {
>>
>> @GET
>> public Book get(String id) {
>> if (!isValidId(id)) {
>> throw new BadRequestException();
>> } else {
>> try {
>> return myClient.get(Book.class);
>> } catch (ClientBadRequestException ex) {
>> throw ServerErrorException();
>> }
>> }
>> }
>>
>> }
>>
>> I think it's not cool, not a big problem but is not ideal...
>
> I see. Perhaps it's a matter of personal preference. For instance, I'd much rather see people explicitly doing something about client exceptions thrown as part of a resource method. Either something like the above, or by registering a custom exception mapper that would just rethrow a proper server exception, which would be then mapped in a standard way.
>
> IOW, for me the example above is why i think it's good to distinguish between client and server exceptions.
>
> Marek
>
>> Sergey
>>
>>> It appears it all revolves around the fact that right now there is an
>>> agreement that some of the (new) Response methods do not work well on
>>> the server side.
>>> Thus one approach is to split it into Client & (server) Response.
>>> I wonder what else can we do...
>>>
>>> Cheers, Sergey
>>>
>>>> Marek
>>>>
>>>> On Mar 28, 2012, at 11:59 AM, Sergey Beryozkin wrote:
>>>>
>>>>> Continuing from the other thread:
>>>>>
>>>>>
>>>>> Note I'm not proposing for WAE to become the root exception type for
>>>>> all the exceptions which may originate from processing the HTTP
>>>>> request at the JAX-RS level but only for the exceptions identifying
>>>>> the server errors.
>>>>>
>>>>> The client code will be able to:
>>>>>
>>>>> throw new WebApplicationException(400);
>>>>> throw new BadClientRequestException();
>>>>>
>>>>> I believe the runtime or custom user WebApplicationException mappers
>>>>> have to be able to catch BadClientRequestException. In this particular
>>>>> case it seems not intuitive to me having the two exception instances
>>>>> identifying the same error condition being not related to each other.
>>>>>
>>>>>
>>>>> Now, here is the client code:
>>>>>
>>>>> String string = request.get(String.class);
>>>>>
>>>>> We are thinking of introducing 5+ exceptions identifying the server
>>>>> errors (or errors reported by the server).
>>>>>
>>>>> Much depends upon what is decided on the relationship between
>>>>> WebApplicationException & exceptions like BadClientRequestException.
>>>>>
>>>>> I'd prefer them be related so that I can write on the client side:
>>>>> try {
>>>>> String string = request.get(String.class);
>>>>> } catch (NotFoundException ex) {
>>>>> // retry with the different address
>>>>> } catch (WebApplicationException ex) {
>>>>> // catches all the other errors reported by the server, including
>>>>> BadClientRequestException
>>>>> } catch (ClientException ex) {
>>>>> }
>>>>>
>>>>> The runtime maps the server error codes to individual exceptions such
>>>>> as NotFoundException, etc, assuming the matching classes are
>>>>> available, otherwise simply wrap it into WebApplicationException()
>>>>>
>>>>> Does it make sense ?
>>>>>
>>>>> Sergey
>>>>>
>>>>> On 27/03/12 17:29, Marek Potociar wrote:
>>>>>>
>>>>>> On Mar 25, 2012, at 7:07 PM, Sergey Beryozkin wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm having one particular concern/question about introducing child
>>>>>>> exceptions to do with individual error conditions (400, 404, etc).
>>>>>>>
>>>>>>> I think that introducing them will require the client runtime to
>>>>>>> throw those child exceptions instead of some base exception (such as
>>>>>>> WAE), otherwise the client code catching sat NotFoundException won't
>>>>>>> be executed if all the client runtime does is throws new
>>>>>>> WebApplicationException(404).
>>>>>>>
>>>>>>> Can we agree it would be the case ?
>>>>>>
>>>>>> Sounds reasonable to me (for the typed-response retrieval use case).
>>>>>>
>>>>>>> The other thing that needs to be agreed upon is this: the exceptions
>>>>>>> to do with the server errors are only thrown when a typed response
>>>>>>> is expected back, example,
>>>>>>>
>>>>>>> get(Book.class) or similar
>>>>>>
>>>>>> Yes that's the expectation.
>>>>>>
>>>>>> Marek
>>>>>>
>>>>>>> Sergey
>>>>>>>
>>>>>>> On 14/03/12 16:19, Sergey Beryozkin wrote:
>>>>>>>> Hi,
>>>>>>>> On 14/03/12 15:53, Marek Potociar wrote:
>>>>>>>>> Hi Sergey,
>>>>>>>>>
>>>>>>>>> just wanted to check if there is any progress with the exception
>>>>>>>>> proposal write-up?
>>>>>>>>>
>>>>>>>>
>>>>>>>> I thought we came to the agreement - but I've cloned the repo and
>>>>>>>> will
>>>>>>>> attach a diff to the JIRA with the proposed code changes - there
>>>>>>>> might
>>>>>>>> be some delay but I'm on it
>>>>>>>>
>>>>>>>> thanks, Sergey
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Marek
>>>>>>>>>
>>>>>>>>> On 03/05/2012 09:23 PM, Santiago Pericas-Geertsen wrote:
>>>>>>>>>> Sergey,
>>>>>>>>>>
>>>>>>>>>> Still catching up with some e-mails. Do we already have a concrete
>>>>>>>>>> proposal for the exact number of client and server exceptions
>>>>>>>>>> that we
>>>>>>>>>> want to include? If so, please point me to it. Otherwise, we should
>>>>>>>>>> put this in writing for the sake of this discussion. Did you
>>>>>>>>>> volunteer for that? ;)
>>>>>>>>>>
>>>>>>>>>> -- Santiago
>>>>>>>>>>
>>>>>>>>>> On Mar 5, 2012, at 11:06 AM, Sergey Beryozkin wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi
>>>>>>>>>>> On 05/03/12 15:05, Santiago Pericas-Geertsen wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Mar 1, 2012, at 7:41 AM, Sergey Beryozkin wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> On 01/03/12 12:11, Sergey Beryozkin wrote:
>>>>>>>>>>>>>> by the way, just spotted
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://java.net/projects/jax-rs-spec/sources/git/content/src/jax-rs-api/src/main/java/javax/ws/rs/core/MessageProcessingException.java?rev=62bb71340b7c156684858dac5c9af09aec50430c
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ValidationException is there too - but that is OK -
>>>>>>>>>>>>> MessageProcessingException seem problematic though, MBR& MBW are
>>>>>>>>>>>>> typed to throw WebApplicationException& InputStream already
>>>>>>>>>>>>
>>>>>>>>>>>> Could you elaborate as to why you think it's problematic? I see
>>>>>>>>>>>> that it doesn't fit in the proposal that you have below, but what
>>>>>>>>>>>> if it extended WebApplicationException (client& server)?
>>>>>>>>>>>
>>>>>>>>>>> Sounds reasonable.
>>>>>>>>>>> The question is then, how it will 'co-exist' with other server
>>>>>>>>>>> side
>>>>>>>>>>> exceptions which are also WebApplicationException children ?
>>>>>>>>>>>
>>>>>>>>>>> Example, I'm assuming we will have BadClientRequestexception and
>>>>>>>>>>> ServerErrorException. The message read failure can be mapped to
>>>>>>>>>>> BadClientRequestException and the message write failure can be
>>>>>>>>>>> mapped to ServerErrorException. Being also able to catch
>>>>>>>>>>> MessageProcessingException won't help the runtime to decide what
>>>>>>>>>>> exactly it can be mapped to (400 or 500), so more enhancements
>>>>>>>>>>> will
>>>>>>>>>>> be needed (MessageReadProcessingException,
>>>>>>>>>>> MessageWriteProcessingException ?).
>>>>>>>>>>> Additionally, it can happen on the client side on the write...
>>>>>>>>>>>
>>>>>>>>>>> At th moment it appears that the providers throwing either
>>>>>>>>>>> WebApplicationException or IOException is a good way of indicating
>>>>>>>>>>> that some kind of message processing exception has occurred
>>>>>>>>>>> with the
>>>>>>>>>>> cause exceptions also available
>>>>>>>>>>>
>>>>>>>>>>> Sergey
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -- Santiago
>>>>>>>>>>>>
>>>>>>>>>>>>>> Should that be gone ? as a summary we seem to have agreed:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - WebApplicationException serves as the base server side
>>>>>>>>>>>>>> exception and
>>>>>>>>>>>>>> can be used on both ends
>>>>>>>>>>>>>> - a limited number of child WebApplicationExceptions is
>>>>>>>>>>>>>> introduced
>>>>>>>>>>>>>> - InvocationException gets removed
>>>>>>>>>>>>>> - ClientInvocation is 'promoted' to represent the base
>>>>>>>>>>>>>> client-side
>>>>>>>>>>>>>> exception
>>>>>>>>>>>>>> - a limited number of child ClientExceptions is introduced
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sergey
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 22/02/12 15:11, Sergey Beryozkin wrote:
>>>>>>>>>>>>>>> Sounds like we agree more than we disagree :-)
>>>>>>>>>>>>>>> Either way, I support your idea that having the child
>>>>>>>>>>>>>>> exceptions
>>>>>>>>>>>>>>> can be
>>>>>>>>>>>>>>> liked by some/quite a few users,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers, Sergey
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 22/02/12 15:00, Bill Burke wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 2/22/12 9:10 AM, Sergey Beryozkin wrote:
>>>>>>>>>>>>>>>>> On 22/02/12 13:41, Bill Burke wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 2/22/12 8:07 AM, Sergey Beryozkin wrote:
>>>>>>>>>>>>>>>>>>> Hi Bill
>>>>>>>>>>>>>>>>>>> On 22/02/12 12:46, Bill Burke wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 2/21/12 12:06 PM, Sergey Beryozkin wrote:
>>>>>>>>>>>>>>>>>>>>> On 21/02/12 10:53, Marek Potociar wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 02/20/2012 03:35 PM, Sergey Beryozkin wrote:
>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Sounds good.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> What are the specific exceptions proposed for inclusion
>>>>>>>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>>>>>>>> spec?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> No new exceptions are to be *initially* added
>>>>>>>>>>>>>>>>>>>>> according to
>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>> specific
>>>>>>>>>>>>>>>>>>>>> proposal but it makes it possible to add finer-grained
>>>>>>>>>>>>>>>>>>>>> exceptions
>>>>>>>>>>>>>>>>>>>>> extending the base ones.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> - WebApplicationException serves as the base for all the
>>>>>>>>>>>>>>>>>>>>> problems
>>>>>>>>>>>>>>>>>>>>> originated at the server side.
>>>>>>>>>>>>>>>>>>>>> - ClientException continues to be the base exception
>>>>>>>>>>>>>>>>>>>>> representing
>>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>> sort of the client-side error but also enhanced at the
>>>>>>>>>>>>>>>>>>>>> cost of
>>>>>>>>>>>>>>>>>>>>> InvocationException which is to be dropped
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> If we all agree that it makes sense so far then lets
>>>>>>>>>>>>>>>>>>>>> review next
>>>>>>>>>>>>>>>>>>>>> what
>>>>>>>>>>>>>>>>>>>>> additional exceptions such as NotFoundException, etc,
>>>>>>>>>>>>>>>>>>>>> representing
>>>>>>>>>>>>>>>>>>>>> server-side exceptions, can be added.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Bill proposed few exception classes; IMHO we should
>>>>>>>>>>>>>>>>>>>>> limit the
>>>>>>>>>>>>>>>>>>>>> number to
>>>>>>>>>>>>>>>>>>>>> the ones representing the most common HTTP error code,
>>>>>>>>>>>>>>>>>>>>> here is the
>>>>>>>>>>>>>>>>>>>>> Bill's list:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> MethodNotAllowedException
>>>>>>>>>>>>>>>>>>>>> BadRequestException
>>>>>>>>>>>>>>>>>>>>> NotAcceptableException
>>>>>>>>>>>>>>>>>>>>> InternalServerErrorException
>>>>>>>>>>>>>>>>>>>>> UnauthorizedException
>>>>>>>>>>>>>>>>>>>>> UnsupportedMediaTypeException
>>>>>>>>>>>>>>>>>>>>> NotFoundException
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I'd drop BadRequestException - this can be anything, and
>>>>>>>>>>>>>>>>>>>>> as such
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> base WebApplicationException can do to deal with it.
>>>>>>>>>>>>>>>>>>>>> InternalServerErrorException, UnauthorizedException
>>>>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>>> probably go
>>>>>>>>>>>>>>>>>>>>> too, leaving
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> MethodNotAllowedException
>>>>>>>>>>>>>>>>>>>>> NotAcceptableException
>>>>>>>>>>>>>>>>>>>>> UnsupportedMediaTypeException
>>>>>>>>>>>>>>>>>>>>> NotFoundException
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> 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).
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> You seem to ignore the possibility of client-side
>>>>>>>>>>>>>>>>>>>>>> processing
>>>>>>>>>>>>>>>>>>>>>> failing
>>>>>>>>>>>>>>>>>>>>>> in a request filter/handler chain. Would it make
>>>>>>>>>>>>>>>>>>>>>> sense to also add Request to the client exception?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> OK
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> How about approaching this also with a small set of
>>>>>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>>>> specific
>>>>>>>>>>>>>>>>>>>>>> child exceptions?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Do you mean ConnectionFailedException and few others
>>>>>>>>>>>>>>>>>>>>> ? I'd
>>>>>>>>>>>>>>>>>>>>> probably
>>>>>>>>>>>>>>>>>>>>> add
>>>>>>>>>>>>>>>>>>>>> ConnectionFailedException for a start...
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I agree with adding COnnectionFailedException, I don't
>>>>>>>>>>>>>>>>>>>> agree with
>>>>>>>>>>>>>>>>>>>> removing the excerptions you suggested.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It's really to do with coming up with some very minimal
>>>>>>>>>>>>>>>>>>> set, as
>>>>>>>>>>>>>>>>>>> opposed
>>>>>>>>>>>>>>>>>>> to saying that no, BadRequestException, can not occur
>>>>>>>>>>>>>>>>>>> often
>>>>>>>>>>>>>>>>>>> enough.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> For ex, BadRequestException, can be thrown in a number of
>>>>>>>>>>>>>>>>>>> cases, and
>>>>>>>>>>>>>>>>>>> thus it's no more useful on the client side than the base
>>>>>>>>>>>>>>>>>>> WebApplicationException...Same for
>>>>>>>>>>>>>>>>>>> InternalServerErrorException.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> UnauthorizedException - may be should stay, though the
>>>>>>>>>>>>>>>>>>> jaxrs
>>>>>>>>>>>>>>>>>>> runtime
>>>>>>>>>>>>>>>>>>> itself won't throw it...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> It's not a big deal, if we were indeed to go for adding
>>>>>>>>>>>>>>>>>>> few
>>>>>>>>>>>>>>>>>>> child
>>>>>>>>>>>>>>>>>>> exceptions, if we had 5 or 8 added, the question is how
>>>>>>>>>>>>>>>>>>> far
>>>>>>>>>>>>>>>>>>> should we
>>>>>>>>>>>>>>>>>>> really go... I guess I'm still worried about the class
>>>>>>>>>>>>>>>>>>> explosion more
>>>>>>>>>>>>>>>>>>> than anything else :-)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Well, the JAX-RS 2.0 spec is inconsistent on this sort of
>>>>>>>>>>>>>>>>>> thing. We
>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>> methods in request/responsebuilder for http headers that
>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>> rarely
>>>>>>>>>>>>>>>>>> used
>>>>>>>>>>>>>>>>>> (allow for example) and don't have ones for things that are
>>>>>>>>>>>>>>>>>> often used
>>>>>>>>>>>>>>>>>> (accept).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We should do one or the other across the board. IMO, I
>>>>>>>>>>>>>>>>>> don't
>>>>>>>>>>>>>>>>>> see the
>>>>>>>>>>>>>>>>>> problem with an explosion of methods/classes that cover
>>>>>>>>>>>>>>>>>> hte HTTP
>>>>>>>>>>>>>>>>>> specification. While Sergey may find BadRequestException
>>>>>>>>>>>>>>>>>> unuseful,
>>>>>>>>>>>>>>>>>> somebody else might.
>>>>>>>>>>>>>>>>> I think you've misinterpreted me. I was talking about the
>>>>>>>>>>>>>>>>> utility of
>>>>>>>>>>>>>>>>> BadRequestException while trying to justify the conservative
>>>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>>>> which I believe the spec should take with regard to
>>>>>>>>>>>>>>>>> introducing new
>>>>>>>>>>>>>>>>> classes which to be honest do not add anything new, example,
>>>>>>>>>>>>>>>>> that is
>>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>>> is already covered by the spec/api. That said, I'm not going
>>>>>>>>>>>>>>>>> to spend
>>>>>>>>>>>>>>>>> much time on arguing against extra 3 or whatever classes
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think you misunderstood me :) If you look at
>>>>>>>>>>>>>>>> RequestHeader or
>>>>>>>>>>>>>>>> RequestBuilder, for example, there's methods there that would
>>>>>>>>>>>>>>>> rarely be
>>>>>>>>>>>>>>>> used (i.e. allow). I'm saying either we cover everything or
>>>>>>>>>>>>>>>> we be
>>>>>>>>>>>>>>>> consistent throughout the spec and remove classes/methods
>>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>> rarely (if ever) be used.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>> --
>> Sergey Beryozkin
>>
>> Talend Community Coders
>> http://coders.talend.com/
>>
>> Blog: http://sberyozkin.blogspot.com
>