Forums Register Login

How to return nicely?

+Pie Number of slices to send: Send
Hi,

Suppose I have the following method;



Is this a nice was to return if no customers matching the customer ID was found or what do you think?

Regards,
Kevin
+Pie Number of slices to send: Send
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)
+Pie Number of slices to send: Send
P.S. Also, notice that your method will throw a NullPointerException if customerId is null. This might or might not be something you want.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
 

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.
+Pie Number of slices to send: Send
[Kevin]: Is this a nice was to return

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.
A magnificient life is loaded with tough challenges. En garde tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1061 times.
Similar Threads
The XMLQuery syntax problem
2 complex problems
set the SET method
Queues
reading input from a file into a array
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 08:13:08.