Well, you don't have too many alternatives: 1) throw an exception if no customer is found; I think it's not needed, unless such a case is really exceptional (an error) in your program 2) return a new customer (probably not suitable here, as you are most likely looking for an existing one) 3) just return null (what I would do in most cases)
Joined: Jan 20, 2004
P.S. Also, notice that your method will throw a NullPointerException if customerId is null. This might or might not be something you want.
Originally posted by Andris Jekabsons: P.S. Also, notice that your method will throw a NullPointerException if customerId is null. This might or might not be something you want.
In the case of this particular method, it looks entirely appropriate. I don't believe in bloating code with handling arguments that can only occur due to programming errors. Perhaps a "not null" assertion would be good. Also, the JavaDoc for customerId parameter should say null is a bad value.
For completeness, in the list of things you can do in the "no result found" situation, you should include returning a special well-known "rogue" object, rather than null. You might define a static final customer object called NO_CUSTOMER, with appropriate behaviours. In this particular case, I don't much like that idea, but in other cases, returning a rogue object rather than null can be nice.
Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
There's a perfectly valid point of view that returning null violates the contract of your method because there's no way to specify "might return null" in the method signature. Opinions vary about how evil this is and how much effort you should invest in avoiding it.
Warning - this is going to push the boundaries on "beginner" territory ...
Read up on the "Null object pattern" for more of what Peter was talking about. I agree that it may be tough to come up with a "null customer" ... or maybe not. Say the caller did this:
Returning a customer with name "Unknown" would elminate that if test, and avoid future bugs when some caller forgets to test for null.
Now what if the caller does this:
Maybe that logic doesn't belong in the "null customer". We can still avoid the null - with a new level of effort and complexity:
FoundHandler and NotFoundHandler would presumably be interfaces, perhaps implemented by the same class that calls the method.
It's very common to use null for "not found" but it's really rather ugly and we ought to feel dirty every time we do it. Study up on alternatives even if they seem a little advanced right now.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Oct 30, 2001
Originally posted by Stan James: There's a perfectly valid point of view that returning null violates the contract of your method because there's no way to specify "might return null" in the method signature.
Well, you can call your method getCustomerOrNull(). I've done that sort of thing moderately often. It's a bit clunky, but certainly does help the person writing call-site code to remember to handle null.
I think it's fine. There are two potential issues here: what to return, and how to return. People have been discussing the first, so I'll address the second. You may find some people feel strongly that it is a bad idea to have multiple returns inside a method - they feel that you should have one and only one return, at the end of the method. For example, like this:
Frankly, I think this is silly; it's needlessly more complicated than the original code. I do not hesitate to use multiple returns when it leads to simpler code. But be sure to keep your methods short when you do this, because in long methods it's easy to overlook early returns. You can find a good recent discussion of this here.