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?

  • 1
    What language are you using?
    – ndm
    Jan 5, 2013 at 18:43
  • Java mostly. Could apply in most OOP capable languages with primitives though.
    – anthropomo
    Jan 5, 2013 at 18:46
  • Why are these methods returning NULL? Jan 5, 2013 at 18:55
  • In a manual sound graphing application (long story) I have arrays of primitives where I want either a human entered value or null (or -1). I when interpolating the data I want to iterate over the array and pick out the valid data from the essentially null data.
    – anthropomo
    Jan 5, 2013 at 19:00
  • I would suggest a workaround instead: along with the return value, the methods could have an out variable _ a status (boolean), which indicates if an error has taken place. This is not that elegant, but will work.
    – superM
    Jan 5, 2013 at 19:06

1 Answer 1


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.

  • Your answer has me thinking an int function that I want to return NaN or null should maybe just be declared to throw an exception, and handle that on the caller end like I would the null value. Probably dispense with the wrapper idea altogether with regard to functions. Doesn't solve my other possible use in arrays that I failed to mention in my original question.
    – anthropomo
    Jan 5, 2013 at 19:50
  • anthropomo : In this case, invalid data is expected and valid input, so it is not a case where using exceptions to handle it would be considered good practice, although this is a topic of much (heated?) discussion.....
    – mattnz
    Jan 6, 2013 at 1:52
  • +1: Even if you don't want to go with a full-fledged functional generic option type, you should wrap the primitive in an object that has a semantic meaning in your context. And apart from the fact that using exceptions to control flow is an abominable practice, it would be a far greater hit to efficiency than all the other practices mentioned combined.
    – scrwtp
    Jan 6, 2013 at 12:00
  • @scrwtp good to know. This is why I'm asking.
    – anthropomo
    Jan 6, 2013 at 12:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.