Вы знаете, как обнаружить исключение, которое может передать вызываемый метод и что управление передается вверх по стеку вызовов, пока не найдется соответствующий блок
catch.
Возникает вопрос: должен ли блок
try
улавливать все возможные исключения, которые может посылать содержащийся в нем метод? Нет, если вы хотите получить максимальные преимущества от обработки исключений: упростить кодирование и снизить затраты на сопровождение. В следующей программе при улавливании производится повторная передача, чтобы исключение обрабатывалось другим блоком
catch.
using System;
class WhenNotToCatchApp {
public void Foo() {
try {
Bar(); }
catch(Exception e) {
Console.WriteLine(e.Message); } }
public void Bar() {
try
{
Baz();
}
catch(Exception e)
<
// Bar не нужно это улавливать, поскольку он ничего // не делает, а только передает исключение наверх.
throw;
} }
public void Baz() {
throw new Exception("Исключение, изначально переданное Baz"); }
public static void Main() {
WhenNotToCatchApp test = new WhenNotToCatchAppO; test.FooO; // Этот метод в конечном счете // выведет сообщение об ошибке. } }
В этом примере .йя/-обнаруживает исключение, посылаемое Baz, хотя ничего с ним не делает и лишь пересылает его Foo. Уловив повторно переданное исключение, Foo обрабатывает информацию (в данном случае отображает сообщение об ошибке, являющееся свойством объекта Exception). Вот пара причин, по которым методу, осуществляющему лишь повторную передачу исключения, не следует его улавливать.
Поскольку CLR автоматически продолжает передавать управление вверх по стеку вызовов, пока не обнаружится метод, улавливающий исключение, промежуточные методы могут игнорировать исключения, которые они не могут обрабатывать. Проектируя программу, вы лишь должны гарантировать, что
хоть какой-то
метод улавливает исключение, иначе, как мы говорили, если для переданного исключения не обнаружится блок
catch,
приложение будет прервано.