As I recently posted on StackOverFlow (http://stackoverflow.com/questions/5562655/resharper-bug-incorrect-expression-is-always-true), I was confused with a claim from Resharper that an expression was always true. I found that statement odd, as I was able to imagine some input so that that expression would evaluate to false. My imagination was wrong though. A simple C# example of this is
static void Foo(int someArray)
var length = someArray.Length;
if (someArray != null)
In the example someArray
is never null when evaluating the if-statement, not even when the method Foo
is given null
as input. This is true, because when someArray
would be null, a NullReferenceException would have been thrown when fetching the length of the array, thus not reaching the if-statement. Now I know Resharper can indicate "Possible NullReferenceException", but only when the variable(or field etc) is checked for being null(by default, so not taking into account the NotNullAttribute etc). The parameter someArray
is checked for null in the example, but the check is dismissed since it always evaluates to true
. As a result Reshaper tells me that the check will always yield true, though the root problem(a possible nullreference Exception) is more important but not
shown. This is confusing and lead me, and probably many other, to debug the wrong statement. Therefore I propose as an improvement to Reshaper, to show the "Possible NullReferenceException" as well. That is equivalent to proposing not
to dismiss checks for null always yielding true or false, when determining whether a "Possible NullReferenceException" should be reported.
If the current implementation was chosen by design, may I know what the reasons against my example were?