RFR: 8048020 - Regression on java.util.logging.FileHandler (original) (raw)

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