Правильное использование try .. catch
Должен ли я использовать этот метод выдачи ошибок:
if (isset($this->dbfields[$var])) {
return $this->dbfields[$var];
} else {
throw new FieldNotFoundException($var);
}
или этот стиль:
try {
return $this->dbfields[$var];
} catch (Exception $e) {
throw new FieldNotFoundException($var);
}
... или что-то еще?
быстрое объяснение кода:$this->dbfields - это массив. isset() проверяет, установлена ли переменная, в данном случае, существует ли элемент массива.
ну, стандартная ошибка «ключ массива не существует» (которая даже не является исключением, теперь, когда я думаю об этом), не имела бы смысла в том, как я это использую.
Ответы 7
Второй пример плохой. Вы несете много накладных расходов, чтобы поймать исключение, когда, как вы демонстрируете, исключение так же легко предотвратить. Кроме того, вы также предполагаете, что знаете, почему было сгенерировано это исключение - если было какое-то другое исключение, например, нехватка памяти или что-то в этом роде, вы сообщаете об этом как «поле не найдено», даже если это не так.
Имейте в виду, что try / catch на таких языках, как C++ и Java, очень дороги из-за всего состояния, которое они должны сохранять и восстанавливать. Python, с другой стороны, имеет очень дешевые исключения, и они положительно рекомендуют вам использовать try / except для простой проверки. Но даже в этом случае ловить все и делать вид, что это исключение, все равно плохо.
@Mark - поэтому у меня больше 3500 XP; Я быстро нахожу очевидные ответы! :-)
Выявление «Исключения» в большинстве случаев не считается хорошей практикой, из двух, которые вы указали, я бы использовал вариант 1.
Перехват всех исключений может скрыть другое исключение и замаскировать его как FileNotFoundException.
Вам следует серьезно подумать о том, чтобы изменить формулировку первого предложения. Я не верю, что перехват исключений НИКОГДА не является хорошей практикой. ОЧЕНЬ РЕДКО может быть, но не НИКОГДА.
//First let's do the checks.
if (!isset($this->dbfields[$var]))
throw new FieldNotFoundException($var);
//Now we're in the clear!
return $this->dbfields[$var];
разве это не совсем то, чем был мой первый пример?
Я предпочитаю первый, но если dbfields [$ var] выдает что-то разумное при доступе к несуществующему элементу, я бы предпочел просто вернуть его без проверки.
Мне не очень нравится менять тип исключения, если у меня нет веской причины - также, если вы это сделаете, обязательно постарайтесь сохранить исходное исключение и трассировку стека.
Просто перечитайте свое объяснение.
Я предполагаю, что ваш метод в # 1 будет перехватывать любые исключения, которые могут быть сгенерированы, и просто возвращать bool. Мне определенно не нравится перехват общего исключения в большинстве случаев, поэтому №2 не был бы моим выбором.
"... или что-то еще?"
Ни то, ни другое не очень хорошо, поэтому было бы уместно что-нибудь другое.
Исправьте версию 2, чтобы перехватить правильное исключение, а не все возможные исключения. Опубликуйте это как вариант 3. Я буду поддерживать то, что улавливает конкретное исключение, а не Exception.
Это далеко не безразлично к языку.
Некоторые языки не вызывают ошибок при доступе к несуществующим полям, а предпочтительный шаблон во многом зависит от реализаций массивов, таблиц, объектов и т. д.
С номером 2 вам на самом деле не нужно генерировать исключение, просто распечатайте то, которое вы поймали.