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

Ответ 1

Отчасти это зависит от того, насколько вы агрессивны. Является ли это приложение внутренним или внешним? Скоро ли ваши изменения будут развернуты в живых системах? У вас есть определенные ошибки для исправления или это просто считается катастрофой?

Чтобы сократить количество ошибок как можно быстрее, но с наибольшим риском серьезного ущерба, просто удалите все блоки catch и позвольте исключениям пузыриться. Для более тонкого подхода просто добавьте запись для начала.

Вы также должны поговорить с тем, кто написал приложение, чтобы начать, если это возможно. Попытайтесь выяснить, почему у них так много исключений-глотательных блоков. Действительно ли они понимают исключения? Здесь определенная тактичность, я подозреваю:)

Следующая остановка: модульные тесты...

Ответ 2

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

Ответ 3

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

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

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

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

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

Ответ 4

Измените блоки 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));
}

Ответ 5

вау....

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

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

Ответ 6

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

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

• Я удаляю catch.
• Код переходит к производству.
• Через некоторое время жалобы клиентов на то, что программа перестала работать (он получил исключение).
• Я начинаю расследование проблемы и выясняю, что эта часть системы никогда не работала, и несколько разработчиков пытались найти ошибки, связанные с этой причиной, но так и не нашли проблему. Или, что еще хуже, они нашли проблему и написали эту инструкцию catch для решения этой проблемы.
• Я фиксирую настоящую проблему, которая была пронесена под ковром и сразу же закрыла несколько отчетов об ошибках.

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

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

Заметьте, что в моих рекомендациях также указывается, что вы должны настроить Visual Studio на разрыв во всех исключениях, перейдя в "Отладка/Исключения.../Исключения общего времени выполнения" и установите флажок "Брошенный". Таким образом вы сразу обнаружите исключение.

Ответ 7

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

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

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

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

Ответ 8

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

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

Тем не менее, никто, кажется, не указал наиболее очевидные и самые быстрые в реализации, отправную точку: перейдите в раздел "Отладка → Исключения" и включите "Разрыв, когда исключение выбрано" для параметра "Common Language Runtime Exceptions". Это приведет к тому, что отладчик будет разбиваться на каждое генерируемое исключение (до того, как будет вызываться блок catch catch), поэтому вы сможете протестировать приложение под отладчиком и определить, какие блоки catch блокируют исключения, когда вы пытаетесь чтобы повторить данную ошибку, из которой вы можете затем сделать решение о том, влияет ли этот конкретный блок catch на эту ошибку.

Ответ 9

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

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

Есть ли у вас модульные тесты, которые можно запускать с кодом в отладчике? Было бы целесообразно сделать это с этим.