Должен ли я всегда включать мой код в try... catch блоки?

Возможный дубликат:
Когда использовать блоки try/catch?
Основной код метода полностью внутри try/catch: это плохая практика?
Когда использовать блоки Try Catch

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

Это для С#.

(Возможно, мне не хватает чего-то фундаментального, поскольку я все еще новичок)

EDIT: Похоже, что это был действительно не очень умный вопрос. Единственное, что мы узнали в школе, это использовать try... catch для предотвращения сбоев. То, что мы сделали с исключением, показывало MessageBox, чтобы сообщить пользователю, что "что-то пошло не так, когда пишете этот файл".

Ответ 1

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

Хороший вопрос. Вот связанный с этим вопрос:

Маньяки, владеющие осями, могут быть примерно в любом месте, поэтому: следует ли носить спортивную бронежилетную стойку 24 часа в сутки?

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

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

Ответ 2

Абсолютно нет. Здесь вы найдете отличную статью CodeProject, посвященную работе с исключениями.

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

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

Ответ 3

Нет, вы не должны обертывать весь свой код в try-catch. Я ответил на аналогичный вопрос здесь, на dba.stackexchange.com - сколько накладных расходов на ошибку в СУБД было.

Как правило, вы должны использовать только обработку исключений, если есть что-то конкретное, что вы хотите сделать с сообщением об ошибке, или если неудавшийся код приводит к результатам, которые больше не используются. Если приложение обращено к пользователю, вы, очевидно, не хотите, чтобы они также видели сообщения об исключительных исключениях. Во всех этих случаях вы должны регистрировать сбой... нет смысла в ловушке для исключения, которое вы не планируете обрабатывать (пустой catch = bad). Но в противном случае вам понадобится исключение.

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

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