Исключение нулевого указателя - это индикатор того, что вы используете объект, не инициализируя его.
Например, ниже - класс ученика, который будет использовать его в нашем коде.
public class Student {
private int id;
public int getId() {
return this.id;
}
public setId(int newId) {
this.id = newId;
}
}
Приведенный ниже код дает вам исключение с нулевым указателем.
public class School {
Student obj_Student;
public School() {
try {
obj_Student.getId();
}
catch(Exception e) {
System.out.println("Null Pointer ");
}
}
}
Поскольку вы используете Obj_Student
, но вы забыли инициализировать его, как в правильном коде, показанном ниже:
public class School {
Student obj_Student;
public School() {
try {
obj_Student = new Student();
obj_Student.setId(12);
obj_Student.getId();
}
catch(Exception e) {
System.out.println("Null Pointer ");
}
}
}
0 / не0 вещей, которыми смущен Ваш коллега, вероятно, относятся к тому, когда люди используют числовые значения в качестве успеха указания возвращаемого значения, не истину (т.е. в сценариях удара и некоторых стилях C/C++).
Используя 0 = успех допускает намного большую точность в определении причин отказа (например, 1 = недостающий файл, 2 = недостающая конечность, и так далее).
Как примечание стороны: в Ruby единственные ложные значения являются нолем и ложью. 0 верно, но не в противоположность другим числам. 0 верно, потому что это - экземпляр объекта 0.
DOS и коды выхода из приложений обычно используют 0, чтобы означать успех и ненулевой означать отказ некоторого типа!
коды ошибки DOS 0-255, и, протестировано использование 'errorlevel' синтаксиса означает что-либо выше или включая заданное значение, таким образом, следующие соответствия 2 и выше к первому goto, 1 к второму и 0 (успех) к заключительному!
IF errorlevel 2 goto CRS
IF errorlevel 1 goto DLR
IF errorlevel 0 goto STR
На языках как C не было никакого булева значения, таким образом, необходимо было определить собственное. Они, возможно, работали над нестандартными переопределениями BOOL?
Для языков без созданного в булевом типе единственное соглашение, которое я видел, состоит в том, чтобы определить TRUE как 1 и ЛОЖЬ как 0. Например, в C, if
оператор выполнит выражение if, если условное выражение оценит к чему-нибудь кроме 0.
я даже однажды видел документ инструкций по кодированию, в котором конкретно было сказано для не переопределения ИСТИНЫ И ЛЖИ.:)
при использовании языка, который имеет созданный в булевской переменной, как C++, тогда ключевые слова true
и false
являются частью языка, и Вы не должны полагаться, как они на самом деле реализованы.
Я не могу вспомнить TRUE
являющийся 0
. 0
что-то, что программист C возвратил бы для указания на успех, все же. Это может быть перепутано с TRUE
.
Это не всегда 1
также. Это может быть -1
или просто ненулевое.
На любом языке я когда-либо работал в (возвращение к ОСНОВНОМУ в конце 70-х), ложь рассмотрели 0, и верный было ненулевым.
На языке C, перед C++, не было такой вещи как булевская переменная. Условные выражения были сделаны путем тестирования ints. Нуль означал ложь, и любой ненулевой имел в виду верный. Таким образом, Вы могли записать
if (2) {
alwaysDoThis();
} else {
neverDothis();
}
, К счастью, C++ позволил специализированный булев тип.
Я услышал об и использовал более старые компиляторы где верный> 0, и ложь < = 0.
Это - одна причина, которую Вы не хотите использовать, если (указатель) или если (число) для проверки на нуль они могли бы неожиданно оценить ко лжи.
Точно так же я работал над системами, где ПУСТОЙ УКАЗАТЕЛЬ не был нулем.
Легко запутаться, когда истинные/ложные операторы возврата удара наоборот:
$ false; echo $?
1
$ true; echo $?
0
Забавная вещь состоит в том, что это зависит от языка Ваш, работают с. В Lua верен == нуль, внутренний для производительности.. То же для многих syscalls в C.
По большей части ложь определяется, поскольку 0, и верный ненулевое. Некоторые языки программирования используют 1, некоторое использование-1 и некоторое использование любое ненулевое значение.
Для Unix окружает, хотя, они используют противоположное соглашение.
Большинство команд, которые работают в оболочке Unix, является на самом деле небольшими программами. Они пасуют назад код выхода так, чтобы можно было определить, была ли команда успешна (значение 0), или перестала ли она работать по некоторым причинам (1 или больше, в зависимости от типа отказа).
Это используется в интерпретаторах оболочки sh/ksh/bash в рамках команд if/while/until для проверки условий:
if command then # successful fi
, Если команда успешна (т.е., возвращает нулевой код выхода), код в операторе выполнен. Обычно, команда, которая используется, [команда, которая является псевдонимом для тестовой команды.
Я помню МН/1, не имел никакого булева класса. Вы могли создать немного и присвоить ему результат булева выражения. Затем для использования его необходимо было помнить, что 1 была ложь, и 0 было верно.
Даже сегодня, на некоторых языках (Ruby, шепелявость...) 0 верно, потому что все кроме ноля верно. Чаще 1 верно. Это - общий глюк и таким образом, он иногда полагал, что хорошая практика не полагается 0 являющийся ложью, но делает явный тест. Java требует, чтобы Вы сделали это.
Вместо этого
int x;
....
x = 0;
if (x) // might be ambiguous
{
}
Делают, явный
if (0 != x)
{
}
Я вспоминаю, что выполнение некоторого VB, программирующего в форме доступа, где Верный, было-1.
Общее правило:
Оболочки (включенный DOS) используют "0" в качестве "Никакой Ошибки"... не обязательно верной.
Языки программирования используют ненулевой для обозначения верный.
Однако если Вы находитесь на языке, который позволяет Вашему определять TRUE ЛЖИ, определите его и всегда используйте константы.
Я не уверен, но я могу сказать Вам это: приемы, полагающиеся на базовую природу ИСТИНЫ И ЛЖИ, подвержены ошибке, потому что определение этих значений оставляют до лица, осуществляющего внедрение языка (или, по крайней мере, спецификатор).
Системные вызовы в стандартной библиотеке C обычно возвращаются-1 на ошибке и 0 на успехе. Также Fotran вычислил, если оператор будет (и вероятно все еще делает), переход к одному из трех номеров строки в зависимости от оценки условия к меньше, чем, равному или больше, чем нуль.
, например: ЕСЛИ БЫ (I-15) 10,20,10
протестировал бы на условие меня == 15 перехода для выравнивания 20, если верный (оценивает для обнуления), и строка 10 иначе.
Sam прав относительно проблем доверия специальным знаниям деталей реализации.
Несколько функций в стандартной библиотеке C возвращают целое число 'кода ошибки' как результат. Так как noErr определяется как 0, быстрая проверка может быть, 'если это 0, это в порядке'. То же соглашение несут к коду результата 'процесса Unix'; то есть, целое число, которое дало некоторый inidication о как данный законченный процесс.
В сценариях оболочки Unix, код результата команды, просто выполненной, доступен, и обычно используемый, чтобы иметь значение если команда, за которой 'следуют' или не с 0 успехами значения и чем-либо еще определенное условие неуспеха.
От этого, все подобные тесту конструкции в сценариях оболочки используют 'успех' (то есть, код результата 0) для значения ПРАВДА, и что-либо еще для значения ЛЖИ.
На полностью различной плоскости, цифровые схемы frecuently используют 'отрицательную логику'. то есть, даже если 0 вольт называют 'двоичным 0' и некоторым положительным значением (обычно +5v или +3.3v, но в наше время не редко использовать +1.8v), назван 'двоичным 1', некоторые события 'утверждаются' данным контактом, идущим в 0. Я думаю, что существуют некоторые стойкие к шуму преимущества, но я не уверен в причинах.
Примечание, однако что нет ничего 'древнего' или некоторое 'время переключения' об этом. Все, что я знаю об этом, является основанным на старых соглашениях, но является полностью текущим и релевантным сегодня.
Если ничто иное, удар окружает, все еще используют 0 для истинного, и 1 для лжи.
Я работал в компании с большой суммой старого кода C. Некоторые общие заголовки определили их собственные значения для ИСТИНЫ И ЛЖИ, и у некоторых действительно был TRUE как 0 и ЛОЖЬ как 1. Ведомый к "войнам истины":
/* like my constants better */
#undef TRUE
#define TRUE 1
#undef FALSE
#define FALSE 0
Это могло бы быть в отношении кода результата 0, который в большинстве случаев после того, как процесс выполнил, код результата 0 предназначенных, "Эй, все хорошо работало, никакие проблемы здесь".