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

Question

catch(Exception ex)
{

}

Какой лучший способ продолжить?

Вырвать их всех и дать сбой?Добавить код входа?Окна сообщений?Это в C #.

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

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

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

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

Answer 4

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

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));
}

Answer 5

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

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

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

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

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

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

Answer 6

вау ....

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

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

Answer 7

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

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

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

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

Answer 8

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

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

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

Answer 9

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

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

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