Sorry my fault -- I have read "catch" while the code says "finally"!
On the other hand, I wonder what it actually shall be good for?
> -----Original Message-----
> From: Bill Burke [mailto:bburke_at_redhat.com]
> Sent: Montag, 22. Oktober 2012 18:59
> To: jsr339-experts_at_jax-rs-spec.java.net
> Subject: [jsr339-experts] Re: [jax-rs-spec users] ReaderInterceptor
> example question
>
>
>
> On 10/22/2012 12:53 PM, Markus KARG wrote:
> > When reading the spec I also was wondering about the same question. I
> > think the answer is simple when looking at the response from the
> > client side: It expects some particular data format to come. This
> data
> > format obviously will only be provided if *all* interceptors work
> > correctly. If one of the interceptors fails, that data format will
> > *not* be provided. Example: If the client requests GZIP and does not
> > accept any other transport encoding, it makes no sense to instead
> > provided a non-GZIPped variant. Moreover, it is a violation of the
> > http specification, as a server must not send something that the
> > client did not request or allow (unless the client did not specify
> any
> > encoding at all). In the exact example below (not a writer but a
> > reader) the same would happen but simply reversed: The client
> obviously sent GZIPped and the ungzipping would skip in case of
> failure. What sense does that make?
> > The JAX-RS resource will not be able to deal with the ZIPed data, so
> > the request cannot be processed.
> >
> > To sum up: The code is wrong. It produces an incorrect response. It
> > must be removed from the specification. Instead, the exception have
> to
> > be propagated to the caller, i. e. the JAX-RS implementation, to be
> handled there.
> >
>
> The code is certainly not wrong. I really don't see what you are so
> bother about here.
>
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com