Примечание. Данное диагностическое правило применимо только к языку C++.
Анализатор обнаружил обработчик исключения, который ничего не делает.
Пример кода:
try { ... } catch (MyExcept &) { }
Конечно, такой код вовсе не обязательно ошибочный. Но очень странно просто подавлять исключение, ничего не делая. Такая обработка исключений может скрывать дефекты в программе и усложнить тестирование программы.
Следует реагировать на исключения, например, вписать 'assert(false)':
try { ... } catch (MyExcept &) { assert(false); }
Иногда подобные конструкции используют, чтобы вернуть управление из множества вложенных циклов или рекурсивных функций. Но исключения — очень ресурсоёмкая операция и их следует использовать по назначению, а именно при возникновении нештатных ситуаций, которые должны быть обработаны на более высоком уровне.
Единственное место, где допустимо просто подавлять исключения — это деструкторы. Деструктор не должен бросать исключений. Однако в деструкторах часто непонятно, что делать с исключениями, и обработчик вполне может быть пуст. Анализатор не предупреждает о пустых обработчиках внутри деструкторов:
CClass::~ CClass() { try { DangerousFreeResource(); } catch (...) { } }
Данная диагностика классифицируется как: