WALA/com.ibm.wala.scandroid/source/org/scandroid
Ben Liblit cb6d3b282a Fix Eclipse warnings about redundant null checks and assignments
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.
2017-08-15 09:11:29 -07:00
..
domain Fix Eclipse warnings about unused method parameters 2017-05-26 14:25:03 -07:00
flow Fix Eclipse warnings about redundant null checks and assignments 2017-08-15 09:11:29 -07:00
model Revert "Fix 106 Eclipse warnings about unnecessary else clauses" 2017-03-25 16:29:26 -05:00
prefixtransfer Fix Eclipse warnings about unused method parameters 2017-05-26 14:25:03 -07:00
spec Declare private methods static wherever possible 2017-06-07 08:29:23 -07:00
synthmethod Declare private methods static wherever possible 2017-06-07 08:29:23 -07:00
util Fix Eclipse warnings about redundant null checks and assignments 2017-08-15 09:11:29 -07:00