Rule java:S2447 says not to have a method that returns a Boolean ever return a Null, on the grounds that Boolean is easily confused with boolean and people may assume a Boolean method ALWAYS returns true or false, and they don’t check for Null.
I probably don’t know the latest Java “best practices” consensus, but I’m curious as to why Boolean is specifically singled out. I mean, wouldn’t the same reasoning apply to other boxed types, especially ones with names identical to primitives (except capitalized)? For instance, if a method returns a Double, I might just assume it’s zero or non-zero and forget to check for the Null case.
Thanks for the report. I agree with you, this is a bit inconsistent. We are planning a larger effort to revisit our Java rules in the coming months and see which ones make sense and which ones need to be rethought. I have noted this rule down for further examination according to the point raised by you.
Thanks for your reply. Note that I’m not claiming definitively that it IS inconsistent, only that it SEEMS that way, so I thought maybe you had some insight into why this rule was chosen or why it was specific to Boolean. In fact, when I brought this rule up with our devs, some of them argued strongly that null is legitimate for ANY boxed type, that that’s sort of the point of having a boxed type in the first place (so that it’s an object). I just thought you folks would have your fingers on the pulse of “best industry practices” (though I guess some things are still in contention – not everything is a ‘goto’ )
BTW, from what I’ve seen, a lot of violations of this particular rule (specific to Boolean) are because someone wanted a “third state” (like “unknown”) and used null for that. IOW they weren’t using Boolean because they NEEDED the boxing (e.g. as part of a collection).
It seems to me that an Enum is more appropriate. Since this seems like a common case, does anyone know if Java has added a 3-state enum to its libraries? Or is this a case where everyone has to roll their own?
)