Вопрос-ответ

Why must local variables, including primitives, always be initialized in Java?

Почему локальные переменные, включая примитивы, всегда должны быть инициализированы в Java?

Почему локальные переменные, включая примитивы, всегда должны быть инициализированы в Java? Почему то же самое неприменимо в случае переменных экземпляра?

Переведено автоматически
Ответ 1

В принципе, требование присвоения переменной значения перед ее чтением - это хорошо. Это означает, что вы случайно не прочтете то, чего не собирались. Да, переменные могут иметь значения по умолчанию - но не лучше ли, чтобы компилятор мог вместо этого обнаружить вашу ошибку, если это может доказать, что вы пытаетесь прочитать что-то, что, возможно, еще не было назначено? Если вы хотите присвоить локальной переменной значение по умолчанию, вы всегда можете назначить это явно.

Теперь это нормально для локальных переменных, но для примера и статических переменных компилятор не имеет возможности узнать порядок, в котором будут вызываться методы. Будет ли свойство "setter" вызываться перед "getter"? У него нет способа узнать, поэтому у него нет способа предупредить вас об опасности. Вот почему для примера / статических переменных используются значения по умолчанию - по крайней мере, тогда вы получите известное значение (0, false, null и т.д.) Вместо просто "того, что оказалось в памяти в то время". (Это также устраняет потенциальную проблему безопасности чтения конфиденциальных данных, которые не были явно удалены.)

Совсем недавно был вопрос по этому поводу для C # ... - прочитайте ответы там, так как это в основном одно и то же. Вам также может показаться интересным недавнее сообщение Эрика Липперта в блоге; оно, по крайней мере, относится к той же области, хотя и имеет несколько иную направленность.

Ответ 2

В Java переменные класса и экземпляра принимают значение по умолчанию (null, 0, false), если они не инициализированы вручную. Однако локальные переменные не имеют значения по умолчанию. Если локальной переменной не присвоено значение, компилятор откажется компилировать код, который ее считывает. ИМХО, это приводит к выводу, что инициализация локальной переменной некоторым значением по умолчанию (например, null, что позже может привести к исключению NullPointerException) при ее объявлении на самом деле плохая вещь. Рассмотрим следующий пример:

Object o;
if (<some boolean condition>)
o = <some value>;
else
o = <some other value>;
System.out.println(o);

Инициализация o с помощью null совершенно не нужна, поскольку компилятор Java проверяет во время компиляции, что любой путь к коду инициализируется o (либо с помощью null, либо с некоторым ненулевым значением) перед чтением переменной. Это означает, что компилятор откажется компилировать строку, System.out.println(o); если вы закомментируете любую из двух инициализаций переменной o во фрагменте кода выше.

Это справедливо для Java, и, возможно, только для Java. Я не знаю о таком языке, как C #. Однако в старом добром C (и, возможно, C ++) по-прежнему рекомендуется всегда инициализировать переменные при их объявлении, AFAIK. Такие "олдскульные" языки программирования могут быть причиной того, что рекомендация всегда инициализировать переменные появляется в книгах и дискуссиях о современных языках, таких как Java, где компилятор отслеживает, была ли переменная инициализирована или нет.

Ответ 3

Не совсем верно. Локальные переменные нужно инициализировать, только если они являются ссылочными. Локальную переменную можно оставить неинициализированной, если на нее никогда не ссылались. Например:

int x;  // Valid
int y;
println("y=" + y); // Not valid since y's value has never been assigned
Ответ 4

Что ж, в случае локальной переменной ясно, что это означает "до", поскольку программный поток между объявлением (в методе) и ссылкой является последовательным. В случае полей, объявленных вне метода, компилятор никогда не знает, какой код когда будет использоваться, поэтому он не может сгенерировать ошибку, поскольку, возможно, какой-то другой метод собирается инициализировать поле перед его использованием.

2024-03-01 17:56 java