Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Does / why does Java need to have void methods? Reference:
Any method declared void doesn't return a value.
As far as I can think, every use of void would be better served by returning a status flag, the object being invoked, or null.
This would make every call a statement that is assignable, and would facilitate builder patterns and method chaining. Methods that are only invoked for their effects would usually return a boolean or a generic Success type or throw an exception on failure.
Because there is a a difference between "This function can succeed or fail and is self-aware enough that it can tell the difference" and "There is no feedback about the effect of this function." Without void, you'd endlessly check success codes and believe that you are writing robust software, when in fact you are doing nothing of the sort.
void does not say anything about whether the method or function is self-aware enough to throw as appropriate.
Apr 24, 2017 at 18:33
void type, and Java was designed to follow many of the conventions of the C language family.Success type" anyway? In fact, return values to indicate success are even less important in Java than in C, because Java has exceptions to indicate failure and C doesn't.
Void type acts as a Unit type (e.g. for Generics), though sadly, it is different from void (side note: a cuddly kitten dies every time you invent a new type to fix the type you messed up in the previous version). If anyone is not familiar with Unit types, this is a decent intro: en.wikipedia.org/wiki/Unit_type
Apr 24, 2017 at 19:09
null (in fact this is the only choice), but null is a special thing, any value of reference type in Java may be null (this is another blunder in language design). And, as I said earlier, if you are using Void return type instead of void mark, Java compiler is not your friend.
Apr 26, 2017 at 5:15
null. The fact that null is a member of most type is irrelevant to whether Void is a unit type.
Apr 26, 2017 at 5:29
The original reason why the language has a void type is because like in C, the creators of the language did not want to unnecessarily complicate the syntax of the language with procedures and functions the way Pascal did.
That was the original reason.
Your suggestions:
returning a status flag
That's a no-no. We do not use status flags. If something goes wrong, we report it via exceptions.
the object being invoked
The fluent style of invocations is a recent development. Many of the programmers who are very happily using fluent today and roll their eyes if they ever have to use an interface that does not support it were not even born when Java was created.
returning null
That would force you to declare a method as returning something, when in fact it is not returning anything, so it would be very confusing to someone who is looking at an interface trying to figure out what it does. People would inevitably invent some otherwise useless class that stands for "no return value" so that all functions that do not have anything to return can return a null reference to such a class. That would be clunky. Luckily, there is a solution to this, it is called void. And that's the answer to your question.
int, so a keyword was added subsequent to K&R to indicate 'no return type'.
Apr 26, 2017 at 0:45
Some methods, like System.out.println does not return anything useful, but is called purely for this side effect. void is a helpful indicator for the compiler and for the reader of code that no useful value is returned.
Returning null instead of void means you would just get a NullPointerException the moment you use this value for anything. So you trade a compile time error for a runtime error which is way worse. Furthermore, you would have to define the return type as Object, which would be misleading and confusing. (And chaining would still not work.)
Status codes are usually used to indicate error conditions, but Java has exceptions for this purpose.
Returning this is not possible from static methods.
Returning a generic Success object would have no useful purpose.
One reason is that it can be misleading to ever return anything other than, say, null. Example:
Arrays.sort(a) return?If you argue that a should be returned so that the call can be chained (which seems to be your response judging from your question), then it is no longer clear whether the return value is a copy of the original object, or the original object itself. Both are possible. And yes, you could put it in the documentation, but it's sufficiently ambiguous that you shouldn't create the ambiguity in the first place.
On the other hand, if you argue that null should be returned, that begs the question of what information the return value is possibly providing the caller, and why the programmer should be forced to write return null when it conveys no information.
And if you return something else totally absurd (like the length of a) then it just makes using that return value really confusing -- just think how much more confusing it is to say int len = Arrays.sort(a) instead of int len = A.length!
return null; -- the JVM could just as well mandate that if control falls off the end of a function by way other than an explicit return or throw statement, null is implicitly returned to the caller. IIRC C does that, except that the return value is undefined in that case (it will be whatever value happens to be in the location used for the return value at the time).
return statement. Instead, you get a compiler error telling you about your mistake. Inserting an implicit return null; would be better than “undefined behavior”, but not much. That would be useful only when the return type has no meaning, but where does the compiler draw the conclusion from, that the return value has no meaning, when it is not void?
return truly doesn't add any value…”, well, as said, there is no indicator for the compiler that a return wouldn’t add any value, if there is no void type. It’s actually the opposite, the first assumption is that a method declaring a return type wants to return something useful of the that type. And we didn’t talk about primitive types yet, which don’t have a null value, hence, any default value injected by the compiler would conflict with the range of potentially useful return values.
Returning a boolean which is always equal to true which you suggest, is not only pointless (the return value carries no information), but would actually be misleading. Most of the time, it's best to use return types which only carry as much information as is actually available - that's why in Java you have boolean for true/false rather than returning an int with 4 billion possible values. Likewise, returning a boolean with two possible values where there is only one possible value ("generic success"), would be misleading.
It would also add unnecessary performance overhead.
If a method is used only for its side effect, there is nothing to return, and the return type void reflects exactly that. Potential rare errors can be signalled via exceptions.
One thing that could be improved, would be making void an actual type, such as Scala's Unit. This would solve some issues such as handling generics.
List.add does always return true, but that’s for being compatible with the broader contract of Collection.add, so Set.add may return true or false.
Java is a relatively old language. And in 1995 (When it was created) and shortly thereafter programmers were very concerned about the amount of time a process took control of the processor as well as the consumption of memory. Returning void would eliminate a few clock cycles and a bit of memory consumption from a function call because you would not have to put the return value on the stack, and you would not subsequently have to remove it.
Efficient code does not give you back something you would never use, and therefore putting void into something that has a meaningless return value is a much better practice to be in than returning a success value.
I've read arguments that suggest that the second option (return this) should be the approach instead of void. This is a pretty good idea but it the builder-style approach was not popular at the time Java was created. If it was as popular at that time as it is now, that might have been the approach taken. Returning null is a really bad idea IMO. I wish null was not even in the language at all.
The problem now is that if a method returns an instance of it's own type, it's not clear whether that is a new object or the same one. Often it doesn't (or shouldn't) matter but other times it does matter. I suppose the language could be changed to implicitly return this on void methods. The only issue I can think of with that at the moment is that if the method was later changed to return a new object of the same type, there would be no compilation warnings but that's maybe no a big deal. The current type system doesn't care about these types of changes now. How this interacts with inheritance/interfaces would need some consideration but it would allow old APIs without a builder style to easily be called as if they did.
null were not part of the language, people would be using all sorts of sentinel values that mean "please ignore this argument/return value, it does not contain any sensible value". The problem with null is not the thing itself, only that it tends to be used incorrectly. I'd wager that this problem would only be exaggerated if the standardized null would be replaced with a myriad of custom solutions, where each implementation would behave differently like silently ignoring usage, or throwing special exceptions instead of a standart null pointer exception, etc.
Apr 25, 2017 at 10:50
null is a proper optional type (like, Maybe in Haskell). The problem with nulls in Java is that there's no sane way to immediately decide if a value is nullable in practice or not. This leads to both of: unnecessarily defensive programming (checking for nulls where it's pointless, thereby increasing percentage of poop in the code), and accidental NPEs in production (if forgot to check where it was needed). Yeah, it's partially solved by annotations but they are optional, not always checked, etc. So they won't save you at boundaries with third party code.
Apr 26, 2017 at 5:24
null works fine for this (fine = simple), but standardized optional values with solid semantics are definitely another fine option (fine = safe).
Apr 26, 2017 at 7:23
Another aspect:
Java is a static language with quite strict features. This means that many things that would be quite open or dynamic in other languages (c/f Ruby, Lisp etc.) are strictly determined.
This is a general design decision. The "why" is hard to answer (well, because the designers of the language thought it would be good!). The "what for" is pretty clear: it lets the compiler detect a lot of errors, which is generally a pretty good feature for any language. Secondly, it makes it comparatively easy to reason about the language. For example, it is relatively easy to create formal correctness proves in (subsets of) the Java language; as comparison, that would be virtually impossible in a dynamic language like Ruby et al.
This thinking permeates the language, for example, the enforced declaration of possible exceptions that a method can throw, the separate type of interface vs. class to avoid ambiguous multiple inheritance, and so on. For what it is (a static imperative OOP real-world language with strong focus on compile time error handling) those things are actually quite elegant and powerful. They come closer to theoretical (science'y) languages which are purposefully made just to explore some of these issues than any other real-world language before (at that time, mind you).
So. Having a strict void type is a clear message: this method does not return anything, period. It is what it is. Replacing it by the enforcement to always return something would lead to either much more dynamic behaviour (like in Ruby where every def has an explicit or implicit return value, always), which would be bad for provability and reasoning; or to massive bloat by using some other mechanism here.
(And N.B., Ruby (for example) handles this differently, and its solution is still exactly as acceptable as Java's, because it has a completely different philosophy. For example it throws provability and reasonability completely out of the window while putting a large focus on extremely high expressiveness of the language.)
