Лучшая практика ловли исключений (c # /. Net)

Question

Если у меня есть такой код:

void a()
{
    try
    {
        b();
    }
    catch (MyException)
    {
        // Handle any problems that occurred in b(c(d()))
    }
}

void b()
{
    c();
    // Do something else
}

void c()
{
    d();
    // Do something else
}

void d()
{
    // Do something, throw a MyException if it fails
}

Предполагая, что в любой момент очистка не требуется, лучше всего поместить try {} catch {throw;} вокруг вызова d () в c () и вызова c () в b () или было бы нормально, чтобы исключение из d () пузырилось до a () «естественно» без каких-либо промежуточных блоков try / catch?

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

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

Answer 1

Позвольте этому распространяться, пока вы не справитесь с этим. Если вы не можете справиться с этим, нет смысла ловить это. Итак, вопрос в том, можете ли вы эффективно обработать исключение внутри метода c()?

Answer 2

Большим преимуществом исключений является то, что вы можете иметь дело с проблемами, когда вы можете что-то с ними сделать, а не непосредственно в функции, например, например. Обнаружен отсутствующий файл или в вызывающей функции, или в вызывающей стороне, & c.

Однако, исключения также имеют для обработки где-то вдоль цепочки. Место возникновения этих точек зависит от используемой вами структуры и от того, из чего состоит ее управление исключениями. Ключевой вопрос заключается в следующем: каковы ваши точки входа , в которых разрешение исключения из-под контроля может привести к отрицательным последствиям? Типичные примеры включают

1. Код обработки событий в интерактивных приложениях с пользовательским интерфейсом (который, по крайней мере, в WinForms и ASP.NET можно массово перехватить, предоставив обработчики событий исключений ).
2. Точки интеграции, в которых вы отвечаете на внешние сообщения (например, получение сообщений из очереди, обработка файла, прослушивание именованного канала, реализация службы WCF ).
3. Таймер событий, где вы выполняете фоновую обработку.
4. Методы запуска потока.

Иногда вам также нужно поймать общую техническую ошибку низкого уровня и перевести ее в более специфичное для домена исключение. Обычно это делается в хорошо спроектированных библиотеках, чтобы защитить пользователей от внутренних деталей реализации. В корпоративном приложении вам может потребоваться перехватить определенные исключения SqlException и повторно выбросить их как исключения для конкретного приложения (например, YourApp.UnknownCustomer), чтобы иметь дело с ними на более высоких уровнях логики.

Мой совет: решайте проблемы на самом высоком возможном уровне, но убедитесь, что у ловушек исключений есть разумные исключения для работы. И, кстати, если вы не ненавидите своих пользователей, не отображайте исключение и его трассировку стека! ; -)

Answer 3

В основном нет. Это не предложенный способ справиться с этими ситуациями.

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

Answer 4

Я бы сказал, это зависит от того, что вы хотите делать с информацией.

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

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