Соглашение (я) о попытке / вылове

Question

Что такое соглашение для Try / Catch за пределами явно необходимых мест (например, получение определенного пользовательского ввода)?Хотя повторное использование кода является важной идеей ООП, ожидается ли, что каждый (пример) доступ к массиву должен иметь попытку / улов?Это в первую очередь решение дизайнера о том, что может вызвать исключение, и те части программы, которые должны быть достаточно хорошо отрегулированы, чтобы никогда не создавать исключение?

Пример.Массив игральных карт - это и всегда должно быть 52 карты.Нет попытки / ловить не требуется.Или, так как исключение массива вне границ может вызвать ошибку во время выполнения, и колоду можно будет использовать позже с добавлением джокеров, а затем вставить ее сейчас?

Answer 1

Вы должны ловить только исключения, которые вы можете обработать. То есть Вы не должны иметь повсюду операторы try / catch.

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

Answer 2

Ваш пример немного не в порядке.

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

Попробуйте Catch, чтобы помочь спасти нас от самих себя. Если данный метод закодирован должным образом, то есть очень мало причин использовать их. Под правильным пониманием я подразумеваю, что вы проверяете, что ваши входные данные находятся в ожидаемых диапазонах, и вы достаточно протестировали, чтобы знать, что код не будет «исключен». Конечно, пример «очень мало» включает в себя вызовы неуправляемых ресурсов, таких как объект SqlConnection.

Дело в том, что это костыль, который является последней попыткой спасти что-то полезное от выполнения этого конкретного блока кода.

Если, однако, буквально ничего не поделаешь с исключением, то я бы сказал, что ваш единственный выбор - игнорировать его и позволять ему пузыриться или ловить, регистрировать и отбрасывать.

Answer 3

Трей Нэш в своей книге «Ускоренный C #» рекомендует (как, вероятно, большинство) программировать таким образом, чтобы исключить использование веток try / catch. Большинство попробуйте / ловит, что вы видите, может быть покончено с помощью лучшего программирования. Есть случаи, когда вам это нужно, в основном при работе с файловыми дескрипторами, соединениями с базой данных, в основном в любое время, когда вам нужно использовать оператор using (который за обложками - блок try / finaly) с типом, реализующим IDisposable. Любое использование чего-либо в ОС, находящееся вне вашего контроля, где что-то может пойти не так, использует попытку catch.

И постарайтесь не пользоваться общим

 try {    //some exception thrown }
 catch (Exception ex) {     }

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

Answer 4

Вы должны избегать использования try / catch, так как это очень дорого.В большинстве сценариев вы можете реализовать необходимую проверку, чтобы избежать создания исключений.

Что касается коллекций или массивов, вы можете проверить, сколько элементов в коллекции есть, чтобы избежать ошибок.

Допустимое местогде вы будете использовать try catch, будет при чтении файла или доступе к стороннему ресурсу.

Когда вы ловите исключение, зарегистрируйте его и попытайтесь найти способ его избежать.

Также при повторном вызове исключенияиспользуйте приведенный ниже код попробуйте {

    }
    catch (Exception ex)
    {
        throw;
    }

Надеюсь, что ответит на ваш вопрос.

Answer 5

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

В определенных случаях, когда вы можете знать, что вызываетисключение (например, вы ловите исключение, которое указывает, что соединение с сервером базы данных не работает), вы ловите конкретное исключение и затем генерируете соответствующее сообщение об ошибке для пользователя.

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

Answer 6

Try/Catch говорит само за себя, что вы пытались что-то сделать, что-то произошло (в нашем случае ничего хорошего), и вы пытаетесь поймать это исключение что-то сделать с этой информацией .

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

Если нет, то больше смысла иметь try/finally (например, при доступе к вводу-выводу для распределенных ресурсов, гарантирующих выполнение логики).

Надеюсь, это поможет.

Answer 7

Просто подумал, что я тоже добавлю это в микс.Эрик Липперт сделал отличный пост об этом несколько лет назад:

http://blogs.msdn.com/b/ericlippert/archive/2008/09/10/vexing-exceptions.aspx