V3153. Dereferencing the result of null-conditional access operator can lead to NullReferenceException. Consider removing parentheses around null-conditional access expression.

Анализатор обнаружил потенциальную ошибку, которая может привести к разыменованию нулевой ссылки. После условного доступа к потенциально нулевому элементу результат null-conditional оператора взяли в скобки перед дальнейшим разыменованием. Это может означать одно из двух:

1) Возникнет ошибка, если объект, к которому осуществлялся условный доступ, является пустой ссылкой.

2) Программа всегда работает корректно, так как объект, к которому осуществлялся условный доступ, всегда не равен null. В этом случае такая проверка является лишней.

Рассмотрим первый вариант. Здесь может возникнуть исключение:

var t = (obj?.ToString()).GetHashCode();

Если объект 'obj' окажется равен null, то в выражении 'obj?.ToString()' метод 'ToString()' не будет вызван. Это принцип работы оператора условного доступа. Но метод 'GetHashCode()' всё равно будет вызван, поскольку его вызов уже не будет относиться к оператору условного доступа.

Исправленный вариант кода:

var t = obj?.ToString().GetHashCode();

Здесь, кроме отсутствия опасного разыменования, переменная 't' теперь будет иметь тип 'Nullable<int>', что корректно отражает её содержимое как потенциально содержащее значение null.

Рассмотрим теперь случай, когда разыменование безопасное, а проверка лишняя:

object obj = GetNotNullString();
....
var t = ((obj as String)?.Length).GetHashCode();

Этот код всегда работает корректно. Объект 'obj' всегда имеет тип 'String', а значит проверка после приведения типа избыточна.

Исправленный вариант:

var t = ((String)obj).Length.GetHashCode();

Согласно Common Weakness Enumeration, потенциальные ошибки, найденные с помощью этой диагностики, классифицируются как CWE-476.


Найденные ошибки

Проверено проектов
381
Собрано ошибок
13 764

А ты совершаешь ошибки в коде?

Проверь с помощью
PVS-Studio

Статический анализ
кода для C, C++, C#
и Java

goto PVS-Studio;