Never use assertions to validate arguments of public methods. According to the Java Language Specification , §14.10, "The assert
Statement" [[JLS 2005]]:
Along similar lines, assertions should not be used for argument-checking in public methods. Argument-checking is typically part of the contract of a method, and this contract must be upheld whether assertions are enabled or disabled.
Another problem with using assertions for argument checking is that erroneous arguments should result in an appropriate runtime exception (such as
IllegalArgumentException
,IndexOutOfBoundsException
orNullPointerException
). An assertion failure will not throw an appropriate exception.
Noncompliant Code Example
The method getAbsAdd()
computes and returns the sum of the absolute value of parameters x
and y
. It lacks argument validation, in violation of rule MET00-J. Validate method arguments. Consequently, it can produce incorrect results because of integer overflow or when either or both of its arguments are Math.abs(Integer.MIN_VALUE)
.
public static int getAbsAdd(int x, int y) { return Math.abs(x) + Math.abs(y); } getAbsAdd(Integer.MIN_VALUE, 1);
Noncompliant Code Example
This noncompliant code example uses assertions to validate arguments of a public method.
public static int getAbsAdd(int x, int y) { assert x != Integer.MIN_VALUE; assert y != Integer.MIN_VALUE; int absX = Math.abs(x); int absY = Math.abs(y); assert (absX <= Integer.MAX_VALUE - absY); return absX + absY; }
The conditions checked by the assertions are reasonable. However, the validation code is omitted when executing with assertions turned off.
Compliant Solution
This compliant solution validates the method arguments both by ensuring that values passed to Math.abs()
exclude Integer.MIN_VALUE
and also by checking for integer overflow. Alternatively, the addition could be performed using type long
and the result of the addition stored in a local variable of type long
. This alternate implementation would require a check to ensure that the resulting long
can be represented in the range of the type int
. Failure of this latter check would indicate that an int
version of the addition would have overflowed.
public static int getAbsAdd(int x, int y) { if (x == Integer.MIN_VALUE || y == Integer.MIN_VALUE) { throw new IllegalArgumentException(); } int absX = Math.abs(x); int absY = Math.abs(y); if (absX > Integer.MAX_VALUE - absY) { throw new IllegalArgumentException(); } return absX + absY; }
Risk Assessment
Failure to validate method arguments can result in inconsistent computations, runtime exceptions, and control flow vulnerabilities.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
---|---|---|---|---|---|
MET01-J |
medium |
probable |
medium |
P8 |
L2 |
Related Guidelines
Bibliography
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="324565de-52aa-42fb-81cf-e3e59909946d"><ac:plain-text-body><![CDATA[ |
[[Daconta 2003 |
AA. Bibliography#Daconta 03]] |
Item 7. My assertions are not gratuitous |
]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="25557d06-c024-4115-95fb-eb6488e0f395"><ac:plain-text-body><![CDATA[ |
[[ESA 2005 |
AA. Bibliography#ESA 05]] |
Rule 68. Explicitly check method parameters for validity, and throw an adequate exception in case they are not valid. Do not use the assert statement for this purpose |
]]></ac:plain-text-body></ac:structured-macro> |
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="d6b966e8-9661-47f3-a818-b53ebde5a128"><ac:plain-text-body><![CDATA[ |
[[JLS 2005 |
AA. Bibliography#JLS 05]] |
§14.10, The |
]]></ac:plain-text-body></ac:structured-macro> |