JDK-4140910 : java.io.FileNotFoundException should return more meaningful detail strings
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.io
  • Affected Version: 1.2.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1998-05-21
  • Updated: 1999-01-15
  • Resolved: 1999-01-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.2.0 1.2fcsFixed
Related Reports
Relates :  
JDK-4079140 - IOException should have subclasses to better describe failure
Relates :  
JDK-4167937 - Add GetLastErrorString entry points to JVM and HPI
Description

Name: rm29839			Date: 05/21/98


It is very difficult to determine if a file is available for use.

FileNotFoundException (with the same message)is generated in two cases:

1. The file does not exist.
2. The file exists but is locked by another user.

The absence of the alternate message text means programmers have to elimate
all the probable causes and then assume the improbable:

File file = new File(fileName);
if (file.exists()) { // whew it exists
    if (file.canWrite()) { // whew I'm allowed
       try {
          DataOutputStream = new ...... new FileOutputStream(file);
       catch (FileNotFoundException e) { // I guess not - perhaps someone is using it.
...
Every programmer has to go through these contortions to generate an accurate message
to the program user.

Also note that java.io.File could use an isAvailableRead/Write() function (or similar).
(Review ID: 29111)
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: 1.2fcs INTEGRATED IN: 1.2fcs
14-06-2004
EVALUATION There are two ways to fix this problem. The right way is to define new subclasses of FileNotFoundException that better describe the various failures that can occur while trying to open a file. This has already been suggested (RFE 4079140) and may be considered in a post-1.2 feature release. In the shorter term we could easily arrange for more appropriate text to appear in the detail strings of exceptions thrown by native I/O code. On Unix we should do the equivalent of perror(), and on Win32 the equivalent of FormatMessage. -- mr@eng 6/9/1998
09-06-1998