Value and nullability analysis

Different ways of analyzing values

ReSharper can analyze values in several ways:

• By understanding the behavior of language constructs.

  In the example below, based on the fact that the parameter obj was explicitly checked for nullability, ReSharper reasonably supposes that the value of obj can be indeed 'null' and displays the corresponding warning:

  

• By relying on code annotation attributes ([CanBeNull], [NotNull], [ItemCanBeNull], [ItemNotNull]) when Nullable reference types are disabled.

  In the following example, the method Bar is marked with the [CanBeNull] attribute, Using this information, ReSharper warns you that the return value of Bar can be null, and calling a method on it could lead to a 'null' dereference:

  

  tip

  If necessary, you can make code analysis even more precise with contract annotations. They help you define dependencies between arguments of a function and its return value.

• In C# 8.0 and later, ReSharper can reuse results of the compiler analysis if Nullable reference types are enabled in the project.

tip

You can instantly fix these problems (for example, automatically add a nullability check) using quick-fixes ( Alt+Enter).

Value and nullability analysis modes

ReSharper can analyze values in different modes:

Optimistic

By default, value analysis mode is optimistic. In this mode, ReSharper only warns about possible 'null' dereference if the value was explicitly checked for nullability, or if the symbol is marked with the [CanBeNull] or [ItemCanBeNull] attribute. The optimistic mode is demonstrated in the examples above.

Pessimistic

In this mode, ReSharper warns about possible 'null' dereference in all contexts where the value is not checked for nullability explicitly, unless the symbol is marked with the [NotNull] or [ItemNotNull] attribute.

To change value analysis mode or disable the analysis, configure the Value analysis mode preference on the Code Inspection | Settings page of ReSharper options (Alt+R, O).

Nullable reference types

If nullable reference types (NRT) are enabled, ReSharper reuses the results of C# compiler analysis.

NRT improve overall precision of the nullability analysis, but there are cases when NRT contracts can be violated, for example, when values are coming from code without #nullable context. In such cases you may get false positive warnings for nullability checks (for example, Expression is always 'true' or 'false') . In such cases, you can choose to ignore nullable API contracts and report a problem only when previous operations with the value in your code guarantee that it can or cannot be null.

You can change this behavior right from the Alt+Enter menu:

... or using the Nullable reference types' warnings mode option on the Code Inspection | Settings page of ReSharper options .

When ReSharper ignores nullable API contracts, nullability analysis relies on the program control flow to report redundant null checks. For example:

var myString = ApiMethod();

if (myString is null)
    throw new ApplicationException("the string is null");

// warning 'Expression is always true'
// 'myString' cannot be null because it's already checked for null in our code
if (myString != null)
    Console.WriteLine(myString);

To learn more about NRT and how ReSharper supports them, watch this webinar recording:

Further examples of value analysis

Here are some more examples of ReSharper's value and nullability analysis:

• If a nullability check has been already done with a simple LINQ query, ReSharper tells you that a further nullability check is redundant:

  

• The same happens if you mark a collection with the [ItemNotNull] attribute:

  

• The next example illustrates how value analysis works when the pessimistic mode is enabled. The value of the list was checked for nullability, but not list items. Therefore ReSharper warns here about possible 'null' dereference.