Попросивший исправить ошибки в программе, Вы находите более чем 100 экземпляров

Измените блоки catch следующим образом:

catch (Exception ex)
{
    Logger.Log(String.Format(
        System.Globalization.CultureInfo.InvariantCulture,
        "An exception is being eaten and not handled. "+
        "This may be hiding critical errors.\n"+
        "Exception: {0}",
        ex));
}

вау ....

Я бы не решился вырвать их, потому что есть вероятность, что это просто создаст больше «ошибок». Первым шагом было бы добавить ведение журнала, чтобы вы знали, что происходит. После того, как у вас будет достаточно информации, вы сможете приступить к рефакторингу ... осторожно

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

Решение, которое вы должны выбрать, во многом зависит от среды, в которой вы работаете.

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

1. Я снимаю защелку.
2. Код отправляется в производство.
3. Через некоторое время клиенты пожаловались на то, что программа перестала работать (у него возникло исключение).
4. Я начинаю исследовать проблему и обнаруживаю, что эта часть системы на самом деле никогда не работала, и несколько разработчиков пытались найти ошибки, связанные с этой причиной, но так и не нашли проблему. Или, что еще хуже, они нашли проблему и написали этот оператор catch, чтобы «решить» проблему.
5. Я исправляю реальную проблему, которая была скрыта под ковром, и закрываю сразу несколько отчетов об ошибках.

Хотя этот метод хорошо служил мне (и моим клиентам) в эти годы, есть одно «но». Например, один из моих текущих клиентов - медицинское учреждение, и разработчики были заинтересованы в использовании моих рекомендаций по кодированию. Однако я настоял на том, чтобы они удалили это конкретное правило из руководящих принципов.В то время как в их программном обеспечении ужасно много этих пустых операторов catch (более 100), и эти надоедливые вещи скрывают множество ошибок и постоянно меняют байты, пока я работаю с их программным обеспечением; вы должны быть очень осторожны с приложениями такого типа. В этом сценарии я бы начал с добавления операторов журнала вместо их удаления. После этого вы можете медленно удалять их по одному, если знаете, какие типы исключений возникают и почему предыдущий разработчик вообще добавил этот оператор catch.

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

Дополнительное примечание, в моих рекомендациях также отмечается, что вы должны настроить Visual Studio на прерывание всех исключений, перейдя в Debug / Exceptions ... / Common Language Runtime Exceptions и отметив флажок «Выброшено». Таким образом, вы сразу заметите исключение.

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

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

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

Однако, похоже, никто не указал на наиболее очевидную и быстро реализуемую отправную точку: Перейдите в "Debug -> Exceptions" и включите "Break when exception is thrown" для секции "Common Language Runtime Exceptions". Это заставит отладчик прерывать каждое брошенное исключение (до того, как блок catch программы будет вызван для его обработки), так что вы сможете протестировать приложение под отладчиком и определить, какие блоки catch подавляют какие исключения, когда вы пытаетесь повторить данную ошибку, на основании чего вы сможете сделать вывод о том, влияет ли данный конкретный блок catch на рассматриваемую ошибку.

Предупреждение. Это общий совет, и особенности вашей среды могут сделать его невозможным, например давление времени.

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

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

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

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

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

По мере того, как вы идете и исправляете ошибку за ошибкой (многие не будут вызваны чрезмерно широкими блоками перехвата, просто скрытыми / "отложенными" ими ;-), будут Обязательно работайте в основном "тестируемым" способом: добавьте модульный тест, который отмечает ошибку, подтвердите, что он не работает, исправьте ошибку, повторно запустите модульный тест, чтобы убедиться, что ошибка исчезла. Ваш растущий набор модульных тестов (со всем, что можно имитировать или подделать) будет работать быстро, и вы сможете дешево выполнять повторный запуск во время работы, чтобы как можно скорее выявлять возможные регрессии, когда их все еще легко исправить.

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

И, наконец, удачи !!! - к сожалению, оно вам понадобится ... к счастью, как сказал Джефферсон, «чем больше я работаю, тем больше мне везет»; -)

Один из подходов, который вы могли бы использовать для получения картины происходящего, - это взять каждый из пустых блоков Exception и каждый из них вызвать метод breakOnException (Исключение e) .

Этот метод не должен делать ничего, кроме (скажем) протоколирования. Затем вы можете запустить программу в отладчике с точкой останова для этого метода и наблюдать за достижением точки останова, а затем исследовать причины. К сожалению, это немного трудозатратно.

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