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  */  
}

规则 squid：S00108 （代码块不能为空）不会捕获问题，因为有一个日志记录语句。

这不合理吗？我错过了一些重要的事情吗？

注意：我已经重写了这个问题以澄清我的用例

Answer 1

如果它导致数百个您认为是FP的，那么您应该考虑关闭规则，或excluding it from your project files。

但要回答你的问题：

异常记录的目的是为调查人员留出足够的信息来找出问题的原因。

如果您的信息是详细的，例如

y方法中的x因为frabjous不够白而破坏了

那么也许他们实现了这个目的。但是像

这样的消息呢？

出了点问题

此外，你确切地知道每个异常消息的含义，但总有一天你可能会转向更大更好的事情。下一个支持该系统的人是否具有相同的知识深度？他可能会感谢堆栈跟踪和行号，告诉他从哪里开始寻找......

但最后，我不得不问：为什么你得到并记录如此多的例外情况，你淹没了记录器？

Answer 2

我理解维护堆栈跟踪的论据以及所有这些，但我认为它会使你的日志膨胀为＆lt;错误级别事件。一种解决方案是将消息记录为WARN，并将异常对象记录为DEBUG或TRACE。这样，普通的用户日志配置就不会像通常的堆栈跟踪一样泛滥，但如果有必要，仍然可以获得堆栈跟踪。

Answer 3

（添加另一个答案来解决重写的问题：）

为什么你们都会处理异常和记录它？如果处理了，则没有理由记录。

Answer 4

尝试将整个对象传递给方法而不仅仅是e.getMessage（）LOGGER.info("INFO "e.);

为什么squid：S1166仅在记录捕获的异常时才接受异常消息？

4 个答案: