Returning boolean instead of declaring a void type in Java?

Question

Are there any hard and fast rules regarding returning boolean in a method signature to indicate a successful operation as opposed to declaring void? I find that for more critical operations in my calling method I want to know if an operation completed so I can log any issues. Is this an "inappropriate" use of boolean?

Answer 1

This is an ok paradigm, but if you want to force the caller to handle the case wehre the operation doesn't complete successfully, you might want to throw a checked exception instead.

This pattern does occur in the core Java libraries, though. See File.delete() as an example.

Answer 2

Usually I use Exceptions to signal when something went wrong.

Instead of returning false, you can throw an Exception with a detailed message about what the problem was.

Returning false doesn't give you much information about the problem.

Then, instead of checking for a false return value, just put the method call in try/catch if you expect that the method could easily fail.

Many people will complain that this method is slower. But, the benefits you gain greatly outweigh the slowdown. Besides, if you are using Java speed shouldn't be your #1 concern.

Answer 3

For returning success generally what you see is:

• Return a boolean
• Return void, but throw exception on error
• Return a status code (less common in java).

Can't see anything wrong with returning a boolean for success, unless you'd need information on exception behavior.

Answer 4

I generally find that throwing an exception in the case of a failure is a far better solution than returning a boolean, because generally do not care if the process has succeeded - I only care if it's failed. By using an exception I can provide any amount of information about why the process actually failed.

If exceptions seem distasteful, you can return a custom Status object which contains a boolean and a status message (something like "Added 6 new Foobars!" or "Could not add Foobars because the Foobin is full!"), although that is of course more complex.

Answer 5

It seem ok, but the devil lies into the details. ;-)

Throwing an exception is the main alternative, with pros and cons.

I think you could get more insight by providing precise coding samples...

Answer 6

Only do this in scenarios where it's clear that something has a boolean outcome. Like IsValidCustomer() or some such.

For all other things where you think you could introduce it, it probably means you're dealing with some kind of Exception, and you really don't want to wrap that with a simple boolean true/false, because you can have a variety of flavours (different exceptions) and reasons why something goes wrong, which you would want to know about.

So either let the exception bubble up the stack, or catch it and turn it into a custom exception or log it or whatever.

Answer 7

If there is an unexpected result, throw an exception. If you just want the function to tell you "did I do X" then return a boolean.

Answer 8

In practice, I find that throwing an Exception is the best thing to do when failure means that we need to abort the process. Like, if you're trying to process an order -- bill the customer, arrange shipping, pay sales taxes, etc -- if you can't find the order record, there's probably little point in doing all the other work. You just want to get out of there. Exceptions let you do this easily. Just catch at the bottom of the block, display or log the error, and get out.

On the other hand, if an "error" means that my program takes a different flow path, returning a boolean makes more sense. Like, if I'm looking for a specific customer and if he exists I update his record and if he doesn't I create a new customer record, then it makes a lot of sense to return a boolean, and in the caller test it and when true follow one path and when false the other.

Really this is two very different meanings of the word "error", and they call for different handling. It is quite possible that the same function could do both. Like, on found return true, on not found return false, on I/O error trying to read throw an exception.

Answer 9

Use boolean values to indicate non-exceptional failure outcomes. An example would be a search function. The nominal failure would be not-found. Communicating that outcome with exceptions is unwieldy. Save exceptions for exceptional cases; the difference between not-found and cannot-search.