On Oct 22, 2012, at 2:32 PM, Marek Potociar wrote:
>
> On Oct 22, 2012, at 12:49 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>
>>
>> On Oct 22, 2012, at 12:45 PM, Marek Potociar wrote:
>>
>>> Hi Jan,
>>>
>>> Interesting topic. Frankly I'm not sure if the finally clause is a must have in general. Event though in this case it might, but still not sure... I'd like to hear comments from others in this group.
>>
>> I had checked on SO and found this:
>>
>> http://stackoverflow.com/questions/65035/in-java-does-return-trump-finally
>>
>> There is a pointer to the java spec in one answer.
>
> Err... what is the connection to our use case?
Sorry Marek, my mistake. I shouldn't do two thing at the same time.
Jan
> I thought we're discussing whether one should always "reset" the old input stream in the reader interceptor or not. The technique how one does it is orthogonal, right?
>
> Marek
>
>>
>> Jan
>>
>>
>>>
>>> Marek
>>>
>>> On Oct 21, 2012, at 2:06 PM, Jan Algermissen <jan.algermissen_at_nordsc.com> wrote:
>>>
>>>> Hi
>>>>
>>>> in the spec it says in the reader interceptor example
>>>>
>>>>
>>>> @Override
>>>> Object aroundReadFrom(ReaderInterceptorContext ctx) ... {
>>>>
>>>> InputStream old = ctx.getInputStream();
>>>> ctx.setInputStream(new GZIPInputStream(old));
>>>> try {
>>>>
>>>> return ctx.proceed();
>>>> } finally {
>>>>
>>>> ctx.setInputStream(old);
>>>> }
>>>>
>>>> }
>>>>
>>>>
>>>> Which means that the old input stream will *always* be restore, not just in the exceptional case.
>>>>
>>>> I wonder: am I just making some stupid mistake or is that a bug in the text or is that a pattern that has to be applied to every reader interceptor anyone is going to write?
>>>>
>>>>
>>>> Jan
>>>
>>
>