Java's file-manipulation methods often indicate failure with a return value instead of throwing an exception. The Java Tutorials for Java 7 note:
Prior to the Java SE 7 release, the
java.io.File
class was the mechanism used for file I/O, but it had several drawbacks.
One of these drawbacks is that:
Many methods didn't throw exceptions when they failed, so it was impossible to obtain a useful error message. For example, if a file deletion failed, the program would receive a "delete fail" but wouldn't know if it was because the file didn't exist, the user didn't have permissions, or there was some other problem.
Consequently, programs that ignore the return values from file operations often fail to detect that those operations have failed. Java programs must check the return values of methods that perform file I/O (this is a specific instance of rule EXP00-J. Do not ignore values returned by methods).
Noncompliant Code Example (delete()
)
This noncompliant code example attempts to delete a specified file but gives no indication of its success. The Java Platform, Standard Edition 6 API Specification [[API 2006]] requires File.delete()
to throw a SecurityException
only when the program lacks authorization to delete the file. No other exceptions are thrown, so the deletion can silently fail.
File file = new File(args[0]); file.delete();
Compliant Solution
This compliant solution checks the return value of delete()
.
File file = new File("file"); if (!file.delete()) { System.out.println("Deletion failed"); }
Compliant Solution (Java SE 7)
This compliant solution uses the java.nio.file.Files.delete()
method from Java SE 7 to delete the file.
Path file = new File(args[0]).toPath(); try { Files.delete(file); } catch (IOException x) { System.out.println("Deletion failed"); // handle error }
The Java SE 7 Documentation [[J2SE 2011]] defines Files.delete()
to throw the following exceptions:
Exception |
Reason |
---|---|
|
File does not exist |
|
File is a directory and could not otherwise be deleted because the directory is not empty |
|
An I/O error occurs |
|
In the case of the default provider and a security manager is installed, the |
Since SecurityException
is a runtime exception, it need not be declared. And NoSuchFileException
and DirectoryNotExmptyException
both inherit from IOException
, they will be caught by the compliant solution's catch
clause.
Risk Assessment
Failure to check the return values of methods that perform file I/O can result in unexpected behavior.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
FIO02-J |
medium |
probable |
high |
P4 |
L3 |
Related Guidelines
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="d0ea3c54-0b32-4c42-b48b-3825ef94d68f"><ac:plain-text-body><![CDATA[ |
[[API 2006 |
AA. References#API 06]] |
|
]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="d12f51fa-bd13-4ca4-8932-6293e9d05cfe"><ac:plain-text-body><![CDATA[ |
[[J2SE 2011 |
AA. References#J2SE 11]] |
|
]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="52aca219-ccc8-4f0c-a11e-90e898faacfb"><ac:plain-text-body><![CDATA[ |
[[Seacord 2005 |
AA. References#Seacord 05]] |
Chapter 7, File I/O |
]]></ac:plain-text-body></ac:structured-macro> |