Лучший способ игнорировать тип исключения: множественный блок catch против запроса типа

Question

В некоторых ситуациях нам нравится игнорировать определенный тип исключения (обычно ObjectDisposedException).Это может быть достигнуто с помощью этих двух методов:

try
{
    // code that throws error here:
}
catch (SpecificException) { /*ignore this*/ }
catch (Exception ex)
{
    // Handle exception, write to log...
}

или

try
{
    // code that throws error here:
}
catch (Exception ex)
{
    if (ex is SpecificException) { /*ignore this*/ }
    else
    {
        // Handle exception, write to log...
    }
}

Каковы плюсы и минусы этих двух методов (в отношении производительности , читабельность и т. д.)?

Answer 1

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

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

Answer 2

catch (SpecificException) { /*ignore this*/ }

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

Answer 3

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

try {
    // ...
} catch (IgnoreThisException) {
    // ignore this
} catch (UnableToHandleHereException) {
    throw; // this should be catched by caller
} catch (Exception e) {
    // log the rest
}

Answer 4

Я бы использовал что-то по аналогии со вторым стилем, но инкапсулирую фактическую логику в другом методе:

try
{
    // code that throws error here:
}
catch (Exception ex)
{
    ExceptionHandling.Handle(ex);
}

И внутренне проверил бы тип

if (ex is SpecificException) { /*ignore this*/ }
else
{
        // Handle exception, write to log...
}

1. ИМО более читабельно.
2. Вы не повторяете логику обработки
3. Если вам когда-нибудь понадобится обработать ObjectDisposedException, его будет достаточно легко изменить

Спасибо, E

Answer 5

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

Я не знаю, улучшит ли это конкретно производительность, но JIT должно быть проще для оптимизации.

Answer 6

Второй стиль лучше, потому что вы игнорируете исключение. Он передает намерение лучше, чем первый стиль.

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

С точки зрения производительности заметной разницы не будет.