Исключение нулевого указателя генерируется, когда приложение пытается использовать null в случае, когда требуется объект. К ним относятся:
null
. null
. null
, как если бы это был массив. null
, как если бы это был массив. null
как будто это было значение Throwable. Приложения должны бросать экземпляры этого класса, чтобы указать на другие незаконные использования объекта null
.
Ссылка: http://docs.oracle.com/javase/8/docs/api/java/lang/NullPointerException.html
Я не думаю, что это - проблема компилятора по сути; целочисленное значение никогда не является пустым, но идея приравнять их не недопустима; это - допустимая функция, которая всегда возвращает false. И компилятор знает; код
bool oneIsNull = 1 == null;
компиляции, но дает предупреждение компилятора: The result of the expression is always 'false' since a value of type 'int' is never equal to 'null' of type '<null>'
.
Таким образом, если Вы хотите ошибку компилятора назад, перейдите к свойствам проекта и включите 'предупреждения обработки как ошибки' для этой ошибки, и Вы начнете рассматривать их как повреждающие сборку проблемы снова.
Компилятор все еще генерирует предупреждение при сравнении не допускающего NULL-значения типа с пустым указателем который является просто способом, которым это должно быть. Может быть Ваше предупреждение, что уровень является слишком низким, или это было изменено в последних версиях (я только сделал это в .net 3.5).
Нечетный... компиляция этого с VS2008, предназначаясь для.NET 3.5:
static int F()
{
return 42;
}
static void Main(string[] args)
{
int i = F();
if (i == null)
{
}
}
Я получаю предупреждение компилятора
warning CS0472: The result of the expression is always 'false' since a value of type 'int' is never equal to 'null' of type 'int?'
И это генерирует следующий IL..., который, по-видимому, JIT оптимизирует далеко
L_0001: call int32 ConsoleApplication1.Program::F()
L_0006: stloc.0
L_0007: ldc.i4.0
L_0008: ldc.i4.0
L_0009: ceq
L_000b: stloc.1
L_000c: br.s L_000e
Можно ли отправить фрагмент кода?
2,0 платформы представили nullable тип значения. Даже при том, что литеральная константа "1" никогда не может быть пустой, ее базовый тип (интервал) может теперь быть брошен к типу интервала Nullable. Мое предположение - то, что компилятор больше не может предполагать, что международные типы не nullable, даже когда это - литеральная константа. Я действительно получаю предупреждение при компиляции 2.0:
При предупреждении 1 результатом выражения всегда является 'ложь', так как значение типа 'интервал' никогда не равно 'пустому указателю' типа 'интервал?'
Предупреждение является новым (3.5, я думаю) - ошибка совпадает с, если я сделал 1 == 2
, который достаточно умно определить как никогда не верный.
Я подозреваю, что с полными 3,5 оптимизациями целый оператор будет просто разделен, поскольку это довольно умно с никогда истинными оценками.
В то время как я мог бы хотеть 1==2
для компиляции (для выключения функционального блока, в то время как я тестирую что-то еще, например), я не хочу 1==null
кому.
Это должна быть ошибка времени компиляции, потому что типы являются несовместимыми (типы значения никогда не могут быть пустыми). Довольно грустно, что это не.