While it is true that no runtime errors will be thrown in the case you described, I think that the scope of this rule is to enforce deterministic behaviors.
In the case you described, I would argue that if you want to have an optional boolean @RequestParam, you should use the boxed class Boolean and also add the defaultValue property to it to define what should happen if the user does not provide the parameter.
@GetMapping("/test")
public String testEndpoint(
@RequestParam(value = "test", required = false, defaultValue = "true") final Boolean test) {
return "If 'test' is not provided, it will default to 'true'.";
}
Unless you want to manually handle the null case, of course.
So I think the rule should still report in cases like the one you described
Came here to report this and found an existing thread.
I’d also argue that Sonar should not report this issue for optional boolean parameters.
Using a Boolean is less preferable, because when the reader of the code sees a Boolean, they must think about nullability and how to handle it (either add extra validation to ensure it is not null, or add an extra nullability annotation).
On the other hand, when boolean is used, there is less cognitive load for the reader of the code, as they only have to consider two states (true/false vs. true/false/null).
I think that the scope of this rule is to enforce deterministic behaviors.
The behavior of Spring framework is already deterministic - for any optional request parameters of boolean type Spring always sets the value to false for missing parameters.
Hey there, thanks for raising these arguments. I think that while my main argument still stands, I also agree that it’s not nice to enforce cognitive overload for cases where the default false value is ok with the controller’s logic.
I created this ticket to relax the rule for boolean parameters!