You could punt on server-side exceptions and just have a client
hierarchy. (If we went the ClientResponse route).
On 3/29/12 10:26 AM, Santiago Pericas-Geertsen wrote:
> 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
>>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com