Правильное использование попробовать .. поймать

Question

Должен ли я использовать этот метод метания ошибок:

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() проверяет, установлена ​​ли переменная, в этом случае существует ли элемент массива.

Answer 1

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

Имейте в виду, что try/catch в таких языках, как C++ и Java, являются очень дорогими из-за всего состояния, которое они должны сохранять и восстанавливать. У Python, с другой стороны, есть очень дешевые исключения, и они положительно рекомендуют вам использовать try/except для простой проверки. Но даже в этом случае ловить все и притворяться, что это один из видов исключения, все еще плохо.

Answer 2

Ловля «Исключение» нет, большая часть времени, считается хорошей практикой, из двух отобразился, я хотел бы использовать вариант 1.

Ловлю все исключений может скрыть другое исключение и маскировать его как исключение FileNotFoundException.

Answer 3

//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]; 

Answer 4

Я предпочитаю первый, но если dbfields [$ вар] бросает что-то разумное, когда вы получаете доступ к несуществующему элементу, то я предпочел бы просто вернуть его без проверки.

Мне не очень нравится изменять тип исключения, если у меня нет веской причины - также если вы это сделаете, убедитесь, что вы пытаетесь сохранить исходную трассировку исключения и стека.

Answer 5

Просто перечитайте свои объяснения.

Я предполагаю, что ваш метод там в # 1 поймает любые исключения, которые могут быть выброшены, и просто вернуть bool. Мне определенно не нравится ловить родовое исключение большую часть времени, поэтому № 2 не будет моим выбором.

Answer 6

«... или что-то еще в целом?»

Не очень хорошо, поэтому что-то еще было бы уместно.

Исправить версию 2, чтобы поймать правильное исключение, а не все возможные исключения. Опубликуйте это как вариант 3. Я перевешу что-то, что ловит конкретное исключение вместо Exception.

Answer 7

Это далеко не язык-агностик.

Некоторые языки не будут бросать ошибки для доступа несуществующих полей, а предпочтительный рисунок во многом зависит от реализаций массивов, таблиц, объектов и т.д.