cb6d3b282a
Most of these are harmless, and are best fixed simply by removing the
redundant check or assignment. The one in FlowType.compareBlocks,
however, revealed a real problem. This code checks for nullness of
`a` *after* having called a method on `a`. Assuming that `a` can
indeed be `null` here, the check must come first to avoid a
`NullPointerException`.
In several places, I saw code of this form:
if (thing == null)
assert thing != null : ... ;
I honestly don't understand the purpose of that `if` statement. Why
not just have the `assert` statement there directly? I removed the
seemingly irrelevant `if` statements in these cases, but if this is
some intentional pattern, please explain it to me.
In a few places where nullness is statically known but non-obvious,
add assert statements to point out what's going on to help future
developers.
Upgrade future such warnings to errors to keep us moving in a cleaner
direction.
|
||
|---|---|---|
| .. | ||
| .launchConfigurations | ||
| .settings | ||
| META-INF | ||
| OSGI-INF/l10n | ||
| src/com/ibm/wala/cast/java | ||
| .classpath | ||
| .cvsignore | ||
| .project | ||
| build.properties | ||
| mvncentral.xml | ||
| pom.xml | ||