Охватывает ли все в блоках try/catch защитное программирование?

Ответ 1

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

По моему опыту, 95% всех блоков catch просто игнорируют исключение (catch {}) или просто регистрируют ошибку и реконструируют исключение. Последнее может показаться правильным, но на практике, когда это делается на каждом уровне, вы просто заканчиваете свой журнал, заполненный пятью копиями того же сообщения об ошибке. Обычно эти приложения имеют "игнорировать catch" на самом верхнем уровне (поскольку "мы пытаемся/поймаем на всех нижних уровнях" ), что приводит к очень медленному приложению с большим количеством пропущенных исключений и журналу ошибок, который слишком долго для любой, кто захочет просмотреть его.

Ответ 2

Широкое использование Try... Catch - это не защитное программирование, а просто прибивание труп в вертикальном положении.

Попробуйте... Наконец, можно использовать экстенсивно для восстановления перед лицом неожиданных исключений. Только если вы ожидаете исключения, и теперь, как с этим бороться, вы должны использовать Try..Catch.

Иногда я вижу Try..Catch System.Exception, где блок catch только регистрирует исключение и повторно бросает. Существует не менее 3 проблем с этим подходом:

• Rethrow предполагает необработанное исключение, и поэтому программа должна завершиться, потому что она находится в неизвестном состоянии. Но улов вызывает блокировку "Наконец" под блоком Catch для запуска. В ситуации undefined код в этих блоках finally может сделать проблему еще хуже.
• Код в этих блоках finally изменит состояние программы. Таким образом, любой журнал не будет фиксировать фактическое состояние программы, когда первоначально было выбрано исключение. И расследование будет сложнее, потому что государство изменилось.
• Это дает вам отвратительный опыт отладки, потому что отладчик останавливается на ретроне, а не на исходном броске.

Ответ 3

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

То, что он делает, должно называться "подметать его под ковриком". Это равномерно (void) -выполнение возвращаемого значения состояния ошибки из вызовов методов.

Ответ 4

Термин "защитное программирование" означает запись кода таким образом, что он может восстанавливаться из ситуаций с ошибками или вообще избегать ситуации с ошибкой. Например:

private String name;

public void setName(String name) {
}

Как вы обрабатываете name == null? Вы делаете исключение или принимаете его? Если нет смысла иметь объект без имени, вы должны выбросить исключение. Как насчет имени == ""?

Но... позже вы напишете редактор. Когда вы настраиваете пользовательский интерфейс, вы обнаружите, что есть ситуации, когда пользователь может решить удалить имя или имя может стать пустым, пока пользователь его отредактирует.

Другой пример:

public boolean isXXX (String s) {
}

Здесь защитная стратегия часто возвращает false, когда s == null (избегайте NPE, когда можете).

Или:

public String getName() {
}

Защитный программист может вернуться "", если name == null, чтобы избежать вызова NPE при вызове кода.

Ответ 5

Если вы собираетесь обрабатывать случайные исключения, обрабатывайте их только в одном месте - самой верхней части приложения для целей:

• представляет дружественное сообщение пользователю и
• сохранение диагностики.

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

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

В общем, If... Else намного лучше, чем Try... Catch.

Ответ 6

Ловить случайные исключения - плохо. Что тогда?

• Игнорировать их? Отлично. Сообщите мне, как это работает для них.
• Войдите в систему и продолжайте работать? Думаю, нет.
• Выбросить другое исключение как часть сбоя? Удачи, отлаживая это.

Ловить исключения, для которых вы действительно можете сделать что-то значимое, хорошо. Эти случаи легко идентифицировать и поддерживать.

Ответ 7

Могу ли я просто отложить здесь, что каждый раз, когда один из моих сотрудников пишет подпись метода с "throws Exception" вместо того, чтобы перечислять типы исключений, которые метод действительно бросает, я хочу перейти и застрелить их в голова? Проблема в том, что через некоторое время у вас есть 14 уровней вызовов, все из которых говорят "бросает исключение", поэтому рефакторинг, чтобы заставить их объявить то, что они действительно бросают, - это основное упражнение.

Ответ 8

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

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

Ответ 9

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

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

Ответ 10

В С++ одной причиной написания множества блоков try/catch является получение трассировки стека, где было выбрано исключение. То, что вы делаете, это писать try/catch повсюду, и (если вы не в нужном месте, чтобы справиться с исключением), у вас есть журнал отслеживания, а затем повторно выбрасывает исключение. Таким образом, если исключение пузырится полностью и заставляет программу завершаться, у вас будет полная трассировка стека, где все началось неправильно (если вы этого не сделаете, тогда необработанное исключение С++ будет помогли раскрутить стопку и искоренить любую возможность выяснить, откуда она взялась).

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

Ответ 11

Я думаю, что реальный ответ: "Это зависит". Если блоки try-catch поймают очень общие исключения, я бы сказал, что это защитное программирование так же, как никогда не выезжать из вашего района - это защитное вождение. Попытка (imo) должна быть адаптирована к конкретным исключениям.

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

Ответ 12

Я нашел "try" "catch" блоки очень полезными, особенно если используется какое-либо реальное время (например, доступ к базе данных).

Слишком много? Глаз смотрителя.

Я обнаружил, что копирование журнала в Word и поиск с помощью "find" - если читатель журнала не имеет "найти" или "искать" как часть своих включенных инструментов - это простой, но отличный способ для прокрутки через подробные журналы.

Это, безусловно, кажется "защитным" в обычном смысле этого слова.

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