RFR: 8048020 - Regression on java.util.logging.FileHandler

Daniel Fuchs daniel.fuchs at oracle.com
Fri Jul 4 18:10:30 UTC 2014


On 7/4/14 7:58 PM, Alan Bateman wrote:
> On 04/07/2014 18:25, Daniel Fuchs wrote:
>>
>> Given that nothing is going to be written to the file then maybe I 
>> don't need APPEND.
>> I just don't want the call to FileChannel.open() to truncate the file.
> APPEND should be harmless here, just not needed.
>
>>
>>> Also you catch FileNotFoundException (which is not thrown by 
>>> FileChannel.open) 
>> oh? What will FileChannel.open throw if the file does not exist then? 
>> Is there another
>> exception? Or do you mean it's not possible to know why 
>> FileChannel.open fails?
>> That would be bad...
> All the specific file system exceptions are defined in java.nio.file 
Argh. Thanks for pointing that out. I need NoSuchFileException, not 
FileNotFoundException.
> but it's not clear to me that you only want to handle 
> NoSuchFileException. Don't you want to handle cases where the zombie 
> file can't be opened for other reasons (file permission issues for 
> example that would manifest as an AccessDeniedException)?
hmmm. yes - you're right. I should catch that to and break the loop in 
that case.
So that would become:

  465                             } catch (NoSuchFileException x) {
  466                                 // Race condition - retry once, and if that
  467                                 // fails again just try the next name in
  468                                 // the sequence.
  469                                 continue;
  470                             } catch (IOException x) {
                                      // the file may not be writable for us.
                                      // try the next name in the sequence
                                      break;
                                  }


Thanks for the feedback Alan!
I had missed those cases.

-- daniel

>
> -Alan.




More information about the core-libs-dev mailing list