tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: svn commit: r1090072 - /tomcat/tc6.0.x/trunk/STATUS.txt
Date Fri, 08 Apr 2011 15:19:02 GMT
Konatantin,

On 4/7/2011 9:08 PM, Konstantin Kolinko wrote:
> 2011/4/8  <schultz@apache.org>:
>> Author: schultz
>> Date: Fri Apr  8 00:41:29 2011
>> New Revision: 1090072
>>
>> URL: http://svn.apache.org/viewvc?rev=1090072&view=rev
>> Log:
>> Updated.
>>
>> Modified:
>>    tomcat/tc6.0.x/trunk/STATUS.txt
>>
> 
>> +
>> +* Backport exception logging from revision 1090022
>> +  http://svn.apache.org/viewvc?view=revision&revision=1090022
>> +  +1: schultz
>> +  -1:
> 
> Actually it might be not as useful as it might seem. Deletion failures
> are reported as boolean return value from delete(), not as an
> exception.
> It makes sense to backport the relevant change to delete() calls as well,
> http://svn.apache.org/viewvc?view=revision&revision=1073393

I'm not sure what you mean. The code actually compiles without any
try/catch block there at all, since none of the methods called actually
throw IOException. I suspect the catch-all block was there to prevent
any really weird things from happening and propagating up the stack.

The code comment says "delete at much as possible" implying that there
is a lot of work to do which might be interrupted, but there is only one
file to delete in each case: it either does or does not succeed.

What change were you suggesting that I actually backport? The
replacement of the duplicate code with a method call?

-chris


Mime
View raw message