Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Java's file-manipulation functions methods often indicate failure with a return value , rather than instead of throwing an exception. The Java Tutorial for Java 7 notes:

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.

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, it is easy for file operations to fail silently, if the methods' return values are ignored. Therefore, do not ignore return values of file-based methods. (This rule 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 EXP00-J. Do not ignore values returned by methods.)

Noncompliant Code Example (delete())

This noncompliant code example attempts to delete the a specified file specified, but gives no indication of its success. The [API 2006] defines Java platform requires File.delete() to only throw a SecurityException, if only when the program is not authorized lacks authorization to delete the file [API 2014]. No other exceptions are thrown; , so it is easy for the deletion to fail, with no indication of whycan silently fail.

Code Block
bgColor#FFCCCC

File file = /* initialize */new File(args[0]);
file.delete();

Compliant Solution

This compliant solution checks the return value of delete().:

Code Block
bgColor#ccccFF

File file = new File(args[0]"file");
if (!file.delete()) {
   System.out.println("// Deletion failed");, handle error
}

Compliant Solution

This compliant solution uses the java.nio.file.Files.delete() method from Java

...

SE 7 to delete the file:

Code Block
bgColor#ccccFF
Path file = new File(args[0]).toPath();
try {
  Files.delete(file);
}

...

 catch 

...

(IOException 

...

x) 

...

{
 

...

 

...

// 

...

Deletion 

...

failed, handle error
}

The Java SE 7 Documentation [J2SE 2011] defines file. \[[J2SE 2011|AA. Bibliography#J2SE 11]\] defines {{Files.delete()}} to throw the following exceptions:

Exception

Reason

NoSuchFileException

if the file

File does not exist

DirectoryNotEmptyException

if the file

File is a directory and could not otherwise be deleted because the directory is not empty

IOException

if an

An I/O error occurs

SecurityException

In the case of the default provider

,

and a security manager is installed, the SecurityManager.checkDelete(String) method is invoked to check delete access to the file

...

bgColor#ccccFF

...

Because SecurityException is a runtime exception, it need not be declared. Because NoSuchFileException and DirectoryNotExmptyException both inherit from IOException, they will be caught by the compliant solution's catch clause.

Risk Assessment

Failure to check file operation errors the return values of methods that perform file I/O can result in unexpected behavior.

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

FIO09

FIO02-J

medium

Medium

probable

Probable

high

Medium

P4

P8

L3

L2

Automated Detection

...

ToolVersionChecker

Description

CodeSonar
Include Page
CodeSonar_V
CodeSonar_V

JAVA.FUNCS.IRV

Ignored Return Value (Java)

SonarQube
Include Page
SonarQube_V
SonarQube_V
S899


Related Guidelines

Bibliography

[API

2006 [

2014]

File.delete()

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="0e9d31f2-b3b8-4af4-961c-f57d681bbfda"><ac:plain-text-body><![CDATA[

[J2SE 2011

AA. Bibliography#J2SE 11

]

]

Files.delete()

]]></ac:plain-text-body></ac:structured-macro>

<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="34e3b89c-d547-4bd1-83f7-45b5243f7666"><ac:plain-text-body><![CDATA[

[[Seacord 2005a

AA. Bibliography#Seacord 05]]

Chapter 7

[Seacord 2013]

Chapter 8, "File I/O"

]]></ac:plain-text-body></ac:structured-macro>


...

FIO08-J. Do not log sensitive information outside a trust boundary      12. Input Output (FIO)      FIO10-J. Do not let external processes block on IO buffersImage Added Image Added Image Added