声纳误报,"change condition so that it does not always evaluate to true."

Sonar false positive, "change condition so that it does not always evaluate to true."

Sonar 正在为以下代码提高 "changes this condition so that it does not always evaluate to true"。我咨询了很多人,他们都同意这是误报,我们是不是遗漏了什么?

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 块中出现错误。 但是,如果 searchRequest 为 null,则 try 块中的第一行将抛出 NullPointerException,如果我不在我的 catch 块中检查 null,它将在我的 catch 块中再次中断。让我的方法再次失败,这是我不想要的。

编辑:

由于评论中的一些人要求提供代码来重现错误,我已将其上传到 github https://github.com/shariqislam786/test,该问题也可以在 eclipse 中使用 sonar lint 3.4 重现。

来自 SonarJava 分析器 (5.1.1) 的符号执行引擎提出了一个问题,因为它假设到达 catch 块的唯一方法是至少有 searchRequestnull。这是引擎的限制,暂时不涉及这些情况。以下票证跟踪此限制:SONARJAVA-2669

现在,正如您所说,没有什么能阻止您调用参数为 null 的方法。在这种情况下,NullPointerException 将被抛出,实际上,我们将到达 catch (Exception e) 块,其中 searchRequestnull

SonarJava 因此引发了 误报

现在,关于您的实施选择,我认为像这样处理 null-case(依靠抛出的异常)并不是人们通常期望的。输入方法时显式 null-check 通常更清晰,应该是首选。

请注意,作为一种好的做法,我认为用 @javax.annotation.Nullable 或类似的 nullness[=37= 注释方法的 searchRequest 参数会更清楚] 注释(这个来自 JSR-305)。这将帮助其他开发人员(和 SonarJava 引擎)了解您可以在哪种状态下提供参数,并使其 crystal 清晰。