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