Page History

public void deleteFile(){

Methods return values to communicate failure or success and at other times, to update the caller's objects or fields. Security risks may arise when method return values are ignored or when the invoking method fails to take suitable action on their receipt. When getter methods are named after an action, such as {{ProcessBuilder.redirectErrorStream()}} for example, a programmer may fail to realize that a return value is expected. Note that the only purpose of the {{redirectErrorStream()}} method is report via its return value whether the process builder merges standard error and standard output; the method that actually performs redirection of the error stream is the overloaded single-argument version. It is important to read the API documentation so that return values are not ignored.

{mc}
Another example is ignoring the return value from add() on a HashSet. If duplicate, false will be returned.
{mc}

h2. Noncompliant Code Example (File deletion)

This noncompliant code example attempts to delete a file, but fails to check whether the operation has succeeded.

{code:bgColor=#FFcccc}
  File someFile = new File("someFileName.txt");
  // doDo something with someFile
  someFile.delete();
{code
}

h2. 

public class ReplaceSolution

This compliant solution correctly updates the {{String}} reference {{original}} with the return value from the {{String.replace}} method.

{code:bgColor=#ccccff}
public class DoNotIgnore {
  public static void main(String[] args) {
    String original = "insecure";
    original = original.replace( 'i', '9' );
    System.out.println(original);
  }
}
{code}

See also guideline [FIO02-J. Keep track of bytes read and account for character encoding while reading data].

h2. Risk Assessment

Ignoring method return values can lead to unanticipated program behavior.

|| Guideline || Severity || Likelihood || Remediation Cost || Priority || Level ||
| EXP00-J | medium | probable | medium | {color:#cc9900}{*}P8{*}{color} | {color:#cc9900}{*}L2{*}{color} |


h3. Automated Detection

The Coverity Prevent Version 5.0 *CHECKED_RETURN* checker can detect the instance where Value returned from a function is not checked for errors before being used.

h3. Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this guideline on the [CERT website|https://www.kb.cert.org/vulnotes/bymetric?searchview&query=FIELD+KEYWORDS+contains+EXP02-J].

h2. Other Languages

This guideline appears in the C Secure Coding Standard as [seccode:EXP12-C. Do not ignore values returned by functions].

This guideline appears in the C+\+ Secure Coding Standard as [cplusplus:EXP12-CPP. Do not ignore values returned by functions or methods].

h2. Bibliography

\[[API 2006|AA. Bibliography#API 06]\] method [delete()|http://java.sun.com/javase/6/docs/api/java/io/File.html#delete()] and method [replace()|http://java.sun.com/javase/6/docs/api/java/lang/String.html#replace(char,%20char)]
\[[Green 2008|AA. Bibliography#Green 08]\] ["String.replace"|http://mindprod.com/jgloss/gotchas.html]
\[[MITRE 2009|AA. Bibliography#MITRE 09]\] [CWE ID 252|http://cwe.mitre.org/data/definitions/252.html] "Unchecked Return Value"
\[[Pugh 2009|AA. Bibliography#Pugh 09]\] misusing putIfAbsent


----
[!The CERT Oracle Secure Coding Standard for Java^button_arrow_left.png!|04. Expressions (EXP)]      [!The CERT Oracle Secure Coding Standard for Java^button_arrow_up.png!|04. Expressions (EXP)]      [!The CERT Oracle Secure Coding Standard for Java^button_arrow_right.png!|EXP01-J. Do not confuse abstract object equality with reference equality]