views:

1326

answers:

5

Due to the use of Generics in Java I ended up in having to implement a function having Void as return type:

public Void doSomething() {
    //...
}

and the compiler demands that I return something. For now I'm just returning null, but I'm wondering if that is good coding practice...

I've also tried Void.class, void, Void.TYPE, new Void(), no return at all, but all that doesn't work at all. (For more or less obvious reasons) (See this answer for details)

  • So what am I supposed to return if the return type of a function is Void?
  • What's the general use of the Void class?

EDIT: Just to spare you the downvotes: I'm asking about V‌oid, not v‌oid. The class Void, not the reserved keyword void.

+6  A: 

return null is the way to go.

Bombe
A: 

If, for obscure reasons, you MUST use this type, then indeed returning null seems to be a sensible option, since I suppose return value will not be used anyway.
The compiler will force you to return something anyway.
And this class doesn't seem to have a public constructor so new Void() is not possible.

PhiLho
I wont be a MUST; it is just convention.
Tom Hawtin - tackline
+30  A: 

So what am I supposed to return if the return type of a function has to be Void?

Use return null. Void can't be instantiated and is merely a placeholder for the Class<T> type of void.

What's the point of Void?

As noted above, it's a placeholder. Void is what you'll get back if you, for example, use reflection to look at a method with a return type of void. (Technically, you'll get back Class<Void>.) It has other assorted uses along these lines, like if you want to parameterize a Callable<T>.

Due to the use of generics in Java I ended up in having to implement this function

I'd say that something may be funky with your API if you needed to implement a method with this signature. Consider carefully whether there's a better way to do what you want (perhaps you can provide more details in a different, follow-up question?). I'm a little suspicious, since this only came up "due to the use of generics".

John Feminella
Having to return Void is not so funky after all. It can simply be mandated by e.g. Callable<T>. Sometimes you just don’t need to return something but can not use e.g. Runnable.
Bombe
Void has legitimate uses, as I noted. But he said that "this only came up due to the use of generics". That makes it sound like he did something to a collection that needs to use Void, which I would say is a rather exceptional case.
John Feminella
With collections it would be very strange, indeed.
Bombe
Both Void.class and void.class are Class<Void> but they are not equal. Void is often used as a generic argument in value of Map (or use the Collections.newSetFromMap) and return of AccessController.doPrivileged.
Tom Hawtin - tackline
@Tom: Yeppers. That's why I tagged the "(Technically, you'll get back Class<Void>.)" Should I amend that part or do you think it's accurate as is?
John Feminella
Wouldn't the elegant way be if the compiler allowed you to just do "return;", as with any other method of type void? Is there a reason why you have to return null?
JesperE
Well, they're not quite the same thing. "return;" returns nothing at all. However, Class<Void> is still an object, even if it can't be instantiated.
John Feminella
+8  A: 

There's no way to instantiate a Void, so the only thing you can return is null.

Jon Bright
More accurately, there's no way to instantiate a Void without doing evil things.
Michael Myers
+2  A: 

To make clear why the other suggestions you gave don't work:

Void.class and Void.TYPE point to the same object and are of type Class<Void>, not of Void.

That is why you can't return those values. new Void() would be of type Void but that constructor doesn't exist. In fact, Void has no public constructors and so cannot be instantiated: You can never have any object of type Void except for the polymorphic null.

Hope this helps! :-)

Martijn