Я никогда не должен использовать типы примитивов снова?
Исключение нулевого указателя - это индикатор того, что вы используете объект, не инициализируя его.
Например, ниже - класс ученика, который будет использовать его в нашем коде.
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 ");
}
}
}
8 ответов
Используя помещенные в коробку типы делает , имеют и производительность и проблемы памяти.
При выполнении сравнений (например, (i == 10)), Java должен распаковать тип прежде, чем сделать сравнение. Даже использование i.equals(TEN) использование вызов метода, который является более дорогостоящим и (IMO) более ужасный, чем == синтаксис.
память Ре, объект должен храниться на "куче" (который также получает удар на производительности), а также хранение самого значения.
А подлый глюк? i.equals(j), когда я null.
я всегда использую примитивы, кроме тех случаев, когда это может быть null, но всегда проверять на null перед сравнением в тех случаях.
Во-первых, переключение с использования примитива к использованию объекта только для получения способности установить его в NULL является, вероятно, плохим проектным решением. У меня часто есть споры с моими коллегами о том, является ли пустой указатель значением сигнальной метки, и мое мнение обычно, что это не (и таким образом не должен быть запрещен как значения сигнальной метки, должен быть), но в данном случае Вы стараетесь изо всех сил использовать его в качестве значения сигнальной метки. Не делайте. Создайте булевскую переменную, которая указывает, допустимо ли Ваше целое число, или создайте новый тип, который обертывает булевскую переменную и целое число вместе.
Обычно, при использовании более новых версий Java, я нахожу, что не должен явно создавать или бросать к версиям объекта примитивов из-за поддержки автоупаковки, которая была добавлена некоторое время в 1,5 (возможно, 1.5 само).
Я предложил бы использовать примитивы все время, если у Вас действительно нет понятия "пустого указателя".
Да, VM делает автоупаковку и все, что теперь, но это может привести к некоторым действительно странным случаям, где Вы получите исключение нулевого указателя в строке кода, который Вы действительно не ожидаете, и необходимо начать делать, пустой указатель проверяет каждую математическую операцию. Также можно начать получать некоторые неочевидные поведения, если Вы начинаете смешивать типы и получать странные поведения автоупаковки.
Для плавают/удваивают, можно рассматривать NaN как пустой указатель, но помнить тот NaN! = NaN, таким образом, Вам все еще нужны специальные проверки как! Float.isNaN(x).
было бы действительно хорошо, если бы были наборы, которые поддерживали типы примитивов вместо того, чтобы иметь необходимость потратить впустую время/издержки упаковки.
В Вашем примере, если оператор будет в порядке, пока Вы не перейдете 127 (поскольку Целочисленная автоупаковка будет кэшировать значения до 127 и возвращать тот же экземпляр для каждого числа до этого значения)
, Таким образом, это будет хуже, чем Вы, представляют его...
if( i == 10 )
будет работать, поскольку прежде, но
if( i == 128 )
перестанет работать. Именно по причинам как это я всегда явно создаю объекты, когда мне нужны они, и иметь тенденцию придерживаться примитивных переменных если в весь возможный
Тебя типы POD Java там по причине. Помимо издержек, Вы не можете сделать нормального функционирования с объектами. Целое число является объектом, который должен быть выделен и собрал "мусор". Интервал не.
Если то значение может быть пустым, можно найти, что в дизайне Вы нуждаетесь в чем-то еще.
существует две возможности - или значение является просто данными (код не будет действовать никто по-другому, если это будет заполнено в или не), или это на самом деле указывает, что у Вас есть два различных типов объекта здесь (код действует по-другому, если существует значение, чем пустой указатель)
, Если это - просто данные для дисплея/устройства хранения данных, Вы могли бы рассмотреть использование реального DTO - тот, который не имеет его как первоклассного участника вообще. У тех обычно будет способ проверить, чтобы видеть, было ли значение установлено или нет.
, Если Вы проверяете на пустой указатель в какой-то момент, можно хотеть использовать подкласс потому что, когда существует одно различие, существует обычно больше. По крайней мере, Вы хотите лучший способ указать на Ваше различие, чем, "если primitiveIntValue == пустой указатель", который ничего действительно не означает.
Не переключайтесь на непримитивы только для получения этого средства. Используйте булевскую переменную, чтобы указать, было ли значение установлено или нет. Если Вам не нравится то решение, и Вы знаете, что Ваши целые числа будут в некотором разумном пределе (или не заботьтесь о случайном отказе), используйте определенное значение для указания 'неинициализированный', такие как Целое число. MIN_VALUE. Но это - намного менее безопасное решение, чем булевская переменная.
Когда Вы поняли к тому 'Позже' мысль, немного больше работы должно было быть выполнено во время рефакторинга. Используйте примитивы, если это возможно. (Прописной период), Тогда делают POJOs, если больше функциональности необходимо. Примитивные классы обертки, по-моему, лучше всего используются для данных, которые должны переместиться через провод, означая сетевые приложения. Разрешение аннулирует, поскольку приемлемые значения вызывают головные боли, когда система 'растет'. Очень кодировать потраченный впустую или пропущенный, охраняя, что должно быть простыми сравнениями.