Tag Info

New answers tagged

0

You definitely don't have to. For instance, if you already know that a return can never be null - Why would you want to add a null check? Adding a null check is not going to break anything but it's just redundant. And better not code redundant logic as long as you can avoid it.


7

A definite no. A caller should not ever check if the function it is calling respects its contract. The reason is simple: there are potentially very many callers and it is impractical and arguably even wrong from a conceptual point of view for each and every single caller to duplicate the logic for checking the results of other functions. If any checks are ...


5

If null is a valid return value of the getUser method, then your code should handle that with an If, not an Exception - it is not an exceptional case. If null is not a valid return value of the getUser method, then there is a bug in getUser - the getUser method should throw an exception or otherwise be fixed. If the getUser method is part of an external ...


4

I would argue that the premise of your question is off: why use a null reference to begin with? The null object pattern is a way to return objects that essentially do nothing: rather than return null for your user, return an object that represents "no user." This user would be inactive, have a blank name, and other non-null values indicating "nothing ...


22

Ixrec's answer is good, but I will take a different approach because I believe that it is worth considering. For the purpose of this discussion I will be talking about assertions, since that's the name by which your Preconditions.checkNotNull() has traditionally been known. What I would like to suggest is that programmers often overestimate the degree by ...


1

Generally, I'd say that depends mainly on the following three aspects: robustness: can the calling method cope with the null value? If a null value might result in a RuntimeException I'd recommend a check - unless complexity is low and called/calling methods are created by the same author, and null is not expected (e.g. both private in the same package). ...


40

That depends on how likely getUser and myMethod are to change, and more importantly, how likely they are to change independently of each other. If you somehow know for certain that getUser will never, ever, ever change in the future, then yes it's a waste of time validating it, as much as it is to waste time validating that i has a value of 3 immediately ...



Top 50 recent answers are included