You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Daniel Fagerstrom <da...@nada.kth.se> on 2006/11/02 22:15:59 UTC

Re: Improving display of exceptions in blocks framework - ResourceReader

Vadim Gritsenko skrev:
> Daniel Fagerstrom wrote:
>> Alexander Klimetschek skrev:
>>> the ResourceReader must throw any IOException caught in generate() 
>>> (line 349). This is currently not done because it looks like there 
>>> are cases, where a failed generate should be silently ignored. The 
>>> debug message says "Received an IOException, assuming client severed 
>>> connection on purpose".
>>>
>>> Is this true? Or would it be no harm to throw the exception at that 
>>> place to trigger the standard "Problem in creating the Request" page?
>>
>> No idea why the code just swallow the exception. IMO it is a bad idea. 
>> If there is any sources that throw Exceptions without meaning anything 
>> with it, it should be fixed there instead.
>>
>> I would assume that it fixes some issue but couldn't find any 
>> information about it in the SVN log.
>>
>> Anyone who know anything about it?
> 
> IIRC, when client terminates the connection prematurely (stops the 
> download midway), you would want to:
> 
>  *) stop request processing
>  *) do not show error page
> 
> While this code is probably still working for non-caching pipelines 
> (reader writing directly to socket), I'm not sure that this particular 
> scenario is still possible with caching pipeline (where reader would 
> write to in memory buffer).
> 
> See also CocoonServlet (2.1) lines 1183-1198.

Thanks. I checked in the code and it seem like the reason that an 
IOException is catched instead of a SocketException is that Tomcat5 
wraps the SocketException in some other exception class that implements 
IOException but not SocketException.

Anyway, both SocketException and IOException are wraped in 
o.a.c.ConnectionResetException in the 
AbstractProcessingPipeline.handleException. And the situation is 
(again?) handled in the requestProcessor.service.

So I don't see any reason that the situation should be handled at all in 
the ResourceReader.

So I'll remove the catch statement in the ResourceReader and make my 
self prepared to revert it (or find some other fix) if any problems are 
reported.

/Daniel