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