I am frequently tempted to wrap integers, etc, solely for the purpose of writing methods that can return null. Negative 1 can work in many cases, but too often (especially in sound) it’s a valid return value.
Often, to get around this, I am returning a reference to a larger object that contains the primitive in question and calling a getter. This seems less efficient than the wrapper, and in some cases less encapsulating.
So, are there any penalties with wrapping for this reason? Does anybody do this? Does this smell?
7
One technique that I sometimes use in C/C++ is to have the function return a boolean value indicating whether the function was able to compute its result, and then pass a pointer as a function argument to where the function can store its result. If the function returns true you can grab the value you want using the pointer. For languages which don’t have pointers, such as Java, you can pass in some mutable container object (usually an array) to get a similar effect. This isn’t really common in Java, although I do remember seeing it used once or twice before. This approach has the benefit that you don’t need to wrap primitives, but you do need to create the array in languages like Java.
Scala and Google’s Guava library for Java offer implementations of the Option pattern for doing this sort of thing in a different way. Instead of returning null when your function can’t return a value, you return an instance of Option which has no value, and then the caller uses methods of the returned Option object to determine whether the actual return value was computed by the function or not and to also get the value if it is valid. Since the Option classes are generic, you still have to wrap your primitives anyway, so this approach actually increases the amount of overhead needed to handle the return value. However, Options do make the code easier to understand than checking an Integer return value for null. Also, it makes it obvious from the function signature that the function may not always return a valid value.
Here’s a contrived example of the former approach in Java:
boolean divide(int[] out, int a, int b) {
if (b == 0) return false;
out[0] = a/b;
return true;
}
int x = ...;
int y = ...;
int[] out = new int[1];
if (divide(out, x, y)) {
int d = out[0];
// do something with d
} else {
// deal with division by zero
}
and the latter with the Guava classes:
Optional<Integer> divide(int a, int b) {
if (b == 0) return Optional.absent();
return Optional.of(a/b);
}
int x = ...;
int y = ...;
Optional<Integer> o = divide(x, y);
if (o.isPresent()) {
int d = o.get();
// do something with d
} else {
// deal with division by zero
}
You should also ask yourself if you should be throwing an exception instead of doing this. For example, in the above, it would probably just be better to always do the division and handle the ArithmeticException, or check if y is zero before calling the function. The right decision depends on a number of factors, such as whether the overhead of exception handling is going to be a problem for your use case.
4