5

引用规则的描述（SonarQube 4.5.5）：

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

通过向记录器提供异常类，将堆栈跟踪写入日志。

我们代码库中的问题是：通过遵循告诉，不问原则，我们使用检查异常作为我们认为的正常执行路径的一部分，我们不希望它们导致不合理的大日志消息.

几个例子：服务器响应错误代码，数据库语句执行失败乐观锁定（并发用户）......

我的建议：将此案一分为二。

// 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（代码块不能为空）不会发现问题，因为有一个日志记录语句。

这不合理吗？我错过了什么重要的事情吗？

注意：我重写了问题以澄清我的用例

4

4 回答 4

3

我理解维护堆栈跟踪和所有这些的论点，但我认为它会使你的日志膨胀为 < ERROR 级别的事件。一种解决方案是将消息记录为 WARN，并将异常对象记录为 DEBUG 或 TRACE。这样一来，普通用户日志配置就不会像往常一样被堆栈跟踪淹没，但如果需要，仍然可以获得堆栈跟踪。

于 2017-03-08T13:33:02.893 回答
2

如果它导致了数百个您认为是 FP 的问题，那么您应该考虑关闭该规则，或者将其从您的项目文件中排除。

但要回答你的问题：

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

如果您的消息很详细，例如

y 方法中的 x 坏了，因为 frabjous 不够一天

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

出问题了

?

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

但最后，我不得不问：为什么要获取并记录如此多的异常以致于淹没记录器？

于 2015-10-09T13:05:52.597 回答
0

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

为什么你们都处理异常并记录它？如果已处理，则没有理由登录。

于 2015-10-12T11:18:35.420 回答
0

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

于 2018-05-01T21:21:16.720 回答