Есть ли веская причина игнорировать пойманное исключение?

Question

Ничего себе, я только что получил огромный проект на C # от сторонних разработчиков, и, просматривая мой код, мой инструмент анализа обнаружил кучу того, что он считал плохим. Одно из самых обескураживающих сообщений было:

Exceptions.DontSwallowErrorsCatchingNonspecificExceptionsRule  : 2106 defects 

Разработчики уверяют меня, что у них есть веская причина для всех пустых блоков catch, что иногда попытка с пустыми блоками catch просто игнорирует бесполезные исключения и предотвращает сбой приложения. Я чувствую, что это полицейский и полный BS. Некоторые из примеров, которые я на самом деле искал, были вызовы базы данных, где запись была сохранена в базе данных, и в этом случае, если исключение было проигнорировано, пользователь вернул бы нормальное приглашение, подумал, что все в порядке, и продолжил их работа. На самом деле их работа никогда не была сохранена. Я думаю, что это абсолютно самая ужасная ошибка. В этом случае, они совершенно не правы, бросая этот код в попытке с пустым блоком catch. Но мой вопрос: "Это когда-либо приемлемо в ЛЮБОЙ ситуации?" Я думаю, что нет, но я, как известно, был неправ.

Answer 1

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

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

Answer 2

Следующее относится только к языкам с проверенными исключениями, например, Java:

Иногда метод генерирует проверенное исключение, которое, как вы знаете, не произойдет, например. некоторые API Java ожидают имя кодировки в виде строки и генерируют исключение UnsupportedEncodingException, если данная кодировка не поддерживается. Но обычно я передаю литерал "UTF-8", который, как я знаю, поддерживается, поэтому я теоретически мог бы написать пустой улов.

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

Answer 3

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

Answer 4

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

IMO, легче знать последствия в Java, так как каждый метод должен объявлять все исключения, которые он может генерировать, чтобы вы знали, чего ожидать, но в C # исключение может быть выдано, даже если оно не задокументировано, так что это сложно знать все возможные исключения, которые могут быть сгенерированы каким-либо методом, и при отсутствии этих знаний обычно плохая идея поймать все.