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

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

From: Sergey Beryozkin <sberyozkin_at_talend.com>
Date: Thu, 29 Mar 2012 10:09:21 +0100

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...

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