Почему squid: S1166 не принимает сообщения об исключениях только при регистрации исключенных исключений?

Question

Цитата из описания правила (SonarQube 4.5.5):

// Noncompliant - exception is lost (only message is preserved) 
try { /* ... */ } 
catch (Exception e) { LOGGER.info(e.getMessage()); } 

Предоставляя класс исключения к регистратору трассирование записывается в журнал.

Проблемы в нашей базе коды заключается в следующем: Следуя принцип Tell, don't ask мы используем проверяемые исключения как часть, что мы считаем, нормальные путями выполнения, и мы не хотим, чтобы привести к неоправданно большим журнальным сообщениям ,

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

Моего предложение: Разделить этот случай в два.

// Noncompliant - exception is lost (only message is preserved) 
try { /* ... */ } 
catch (Exception e) { LOGGER.info(e.getMessage()); } 

и

// Compliant - exception is lost (only message is preserved) but there is business logic handling the situation  

try { 
/* ... */ 
} catch (Exception e) { 
    LOGGER.info(e.getMessage()); 
    */ exception handling */ 
} 

Правило кальмар: S00108 (блоки кода не должны быть пустыми) не выявит проблему, так как есть регистрация заявление.

Разве это не разумно? Я пропустил что-то важное?

Примечание: Я переписал вопрос прояснить мой случай использования

Answer 1

Я понимаю аргументы для сохранения трассировки стека и все такое, но я думаю, что это раздувает ваши журналы для события уровня ERROR <. Одним из решений является запись сообщения как WARN и запись объекта исключения в виде DEBUG или TRACE. Таким образом, обычная конфигурация журнала пользователя не будет заполняться бизнес-обычными трассировками стека, но при необходимости можно будет получить трассировку стека.

Answer 2

Если это вызывает сотни, что вы считаете, что FP, то вы должны думать о превращении правила выключения или excluding it from your project files.

Но чтобы ответить на ваш вопрос:

Точка протоколирования исключений является оставить достаточно информации для исследователей, чтобы выяснить причину проблемы.

Если ваши сообщения указаны, например.

крестик в методе у сломала, потому что не был радостный день достаточно

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

Что-то пошло не так

?

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

Но, наконец, я должен спросить: почему вы получаете и протоколирование так много исключений, которые вы затоплению регистратор ?

Answer 3

(Добавление другого ответа на этот вопрос рассматривался как переписано :)

Почему бы вам обоим справиться исключение и лог его? Если он обрабатывается, нет причин для регистрации.