Почему оператор переключения был разработан, чтобы нуждаться в перерыве?
Исключение нулевого указателя - это индикатор того, что вы используете объект, не инициализируя его.
Например, ниже - класс ученика, который будет использовать его в нашем коде.
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 ");
}
}
}
7 ответов
Много ответов, кажется, фокусируются на способности провалиться как причина для требования break оператор.
я полагаю, что это была просто ошибка, должная в основном, потому что, когда C был разработан, было совсем не столько же опыта с тем, как эти конструкции будут использоваться.
липа Peter Van der излагает доводы в его книге "Опытное Программирование C":
Мы проанализировали источники компилятора C Sun для наблюдения, как часто значение по умолчанию проваливается, использовался. Фронтэнд компилятора C ANSI Sun имеет 244 оператора переключения, каждый из которых имеет в среднем семь случаев. Провалитесь происходит во всего 3% всех этих случаев.
, Другими словами, нормальное поведение коммутатора неправильно 97% времени. Это не находится только в компиляторе - наоборот, где проваливаются, использовался в этом анализе, которым это часто было для ситуаций, которые происходят более часто в компиляторе, чем в другом программном обеспечении, например, при компиляции операторов, которые могут иметь или один или два операнда:
switch (operator->num_of_operands) { case 2: process_operand( operator->operand_2); /* FALLTHRU */ case 1: process_operand( operator->operand_1); break; }Случай проваливается, так широко распознан как дефект, что существует даже специальная конвенция комментария, показанная выше, который говорит линту, что "это - действительно один из тех 3% случаев, где проваливаются, был желаем".
я думаю, что это была хорошая идея для C# для требования явного оператора перехода в конце каждого блока случая (все еще позволяя нескольким маркировкам случая быть сложенным - пока существует только единственный блок операторов). В C# у Вас может все еще быть одно падение случая до другого - просто необходимо сделать падение через явный путем перехода к следующему случаю с помощью goto.
Это - слишком плохой Java, не воспользовался возможностью для повреждения от семантики C.
Большим количеством способов c является просто чистым интерфейсом к стандартным идиомам блока. При записи таблице переходов управляемого управления потоком у программиста есть выбор того, чтобы проваливаться или выпрыгивания из "управляющей структуры", и переход требует явной инструкции.
Так, c делает то же самое...
Реализовать устройство Вареного пудинга, очевидно:
dsend(to, from, count)
char *to, *from;
int count;
{
int n = (count + 7) / 8;
switch (count % 8) {
case 0: do { *to = *from++;
case 7: *to = *from++;
case 6: *to = *from++;
case 5: *to = *from++;
case 4: *to = *from++;
case 3: *to = *from++;
case 2: *to = *from++;
case 1: *to = *from++;
} while (--n > 0);
}
}
Операторы выбора в операторы переключения являются просто маркировками.
при включении значения оператор переключения по существу делает goto к маркировке с совпадающим значением.
Это означает, что повреждение необходимо, чтобы не передавать до кода под следующей маркировкой.
Что касается причины , почему это было реализовано этот путь - провалиться природа оператора переключения может быть полезной в некоторых сценариях. Например:
case optionA:
// optionA needs to do its own thing, and also B's thing.
// Fall-through to optionB afterwards.
// Its behaviour is a superset of B's.
case optionB:
// optionB needs to do its own thing
// Its behaviour is a subset of A's.
break;
case optionC:
// optionC is quite independent so it does its own thing.
break;
Если бы случаи были разработаны для повреждения неявно затем, то у Вас не могло бы быть fallthrough.
case 0:
case 1:
case 2:
// all do the same thing.
break;
case 3:
case 4:
// do something different.
break;
default:
// something else entirely.
, Если бы переключатель был разработан для вспыхивания неявно после каждого случая, у Вас не было бы выбора относительно этого. Выбирающая структура переключателя была разработана путем, это должно быть более гибко.
Это устраняет дублирование кода, когда несколько случаев должны выполнить тот же код (или тот же код в последовательности).
С тех пор на уровне ассемблера это не заботится, повреждаетесь ли Вы между каждым или не существует нуль наверху для, проваливаются случаи так или иначе, итак, почему бы не позволить им, так как они предлагают значительные преимущества в определенных случаях.
Поскольку многие здесь указали, это должно позволить единственному блоку кода работать на несколько случаев. Это должно быть более обычным явлением для Ваших операторов переключения, чем "блок кода на случай", Вы указываете в своем примере.
, Если бы у Вас есть блок кода на случай без, проваливаются, возможно, необходимо рассмотреть использование if-elseif-else блока, поскольку это казалось бы более соответствующим.