OnlyOneReturn without DD anomaly

Question

@RequestMapping(value = "/product/baselist", method = RequestMethod.POST)
public ResponseEntity<Object> baseListProductFilters(@RequestBody final ObjectNode json) {
    LOGGER.debug("Gettig all product filters");
    try {
        final int offset = json.get("offset") == null ? OFFSET_AUTOCOMPL
                : json.get("offset").asInt(OFFSET_AUTOCOMPL);
        final int limit = json.get("limit") == null ? LIMIT_AUTOCOMPL : json.get("limit").asInt(LIMIT_AUTOCOMPL);

        return ResponseEntity.status(HttpStatus.OK)
                .body(filterService.getList(getUsername(), ResourceType.PRODUCT, offset, limit));
    } catch (Exception e) {
        LOGGER.error("Error getting product filter list: ", e);
        return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(e);
    }
}

So here is my code. I have PMD code analyser installed. It suggests me that there should be ONLY ONE RETURN. So I did this:

@RequestMapping(value = "/product/baselist", method = RequestMethod.POST)
public ResponseEntity<Object> baseListProductFilters(@RequestBody final ObjectNode json) {
    LOGGER.debug("Gettig all product filters");
    ResponseEntity<Object> toReturn;
    try {
        final int offset = json.get("offset") == null ? OFFSET_AUTOCOMPL
                : json.get("offset").asInt(OFFSET_AUTOCOMPL);
        final int limit = json.get("limit") == null ? LIMIT_AUTOCOMPL : json.get("limit").asInt(LIMIT_AUTOCOMPL);

        toReturn = ResponseEntity.status(HttpStatus.OK)
                .body(filterService.getList(getUsername(), ResourceType.PRODUCT, offset, limit));
    } catch (Exception e) {
        LOGGER.error("Error getting product filter list: ", e);
        toReturn = ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR).body(e);
    }
    return toReturn;
}

There is no more OnlyOneReturn violation but 'DD'-anomaly appears. My client requires OnlyOneReturn not to be ignored. Any ideas how can I solve this issue?

Answer 1

My two cents as a PMD maintainer.

Rules in the controversial ruleset should be taken judiciously. Make sure it actually makes sense to add each. Including the whole ruleset just because it's part of PMD is generally a bad idea. We are working towards building better defaults / have better rules, but in the meantime just be careful.

DataflowAnomalyAnalysis is a poor rule as it currently stands.

• Not all anomalies mean there is an issue / makes sense. UR anomalies mean the code does not even compile. DU anomalies are actually common in code. DD anomalies may at best point to spurious assignments, but don't necessarily mean there is a bug either.
• The rule doesn't properly handle all Java constructs. assert is not handled, for-each is not handled, try-with-resources is not handled properly... There are plenty of open issues on GitHub for this

We do plan to revamp it eventually (but is not a top priority at the moment, since we are working on some other core functionality that we believe have a much greater impact on everyday developer work).

In the meantime, you should probably either disable the rule, or add suppressions as needed.

Please, submit issues if you find more failing scenarios.