Sonar 正在为下面的代码提出“更改此条件,使其不总是评估为真”。我咨询过很多人,他们都同意这是误报,我们是否遗漏了什么?
public SearchResponse getSearchResponse(SearchRequest searchRequest) {
try {
searchRequest.validate();
} catch(VerifyException e) {
///some code to make errorResp
return errorResp
} catch(Exception e) {
String key = searchRequest != null ? serchReqeust.getKey() : null;
Logger.log("some text {}", key);
//some code to make errorResp
return errorResp;
}
}
该错误是在 searchRequest != null
处的通用 catch block 中引发的。
但是,如果 searchRequest 为 null,则 try block 中的第一行将抛出 NullPointerException,并且如果我不在 catch block 中检查 null,它将在 catch block 中再次中断。让我的方法再次失败,这是我不想要的。
编辑:
由于评论中的一些人要求提供代码来重现该错误,我已将其上传到 github https://github.com/shariqislam786/test这个问题也可以在 Eclipse 中使用 sonar lint 3.4 重现。
最佳答案
SonarJava 分析器 (5.1.1) 的符号执行引擎引发了一个问题,因为它假设到达 catch
block 的唯一方法至少是 searchRequest
非null
。这是引擎的限制,目前不包括这些情况。以下票证跟踪此限制:SONARJAVA-2669
现在,正如您所说,没有什么可以阻止您调用参数为 null
的方法。在这种情况下,NullPointerException
将被抛出,实际上,我们将到达 catch (Exception e)
block ,其中 searchRequest
为 空
。
SonarJava 因此引发误报。
现在,关于您的实现选择,我相信像这样处理 null
情况(通过依赖抛出的异常)并不是人们通常期望的。输入方法时显式的 null
检查通常更清晰,应该是首选。
请注意,作为一种好的做法,我认为使用 @javax.annotation.Nullable
或一些类似的 searchRequest
参数注释该方法会更清晰em>nullness 注释(这个来自 JSR-305 )。这将帮助其他开发人员(和 SonarJava 引擎)了解您可以在哪种状态下提供参数,并使其一目了然。
关于java - Sonar 误报, "change condition so that it does not always evaluate to true.",我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/49176838/