Exceptions versus Return Values

In a previous post here, I blogged about checked exceptions and how I felt they are a useful tool in your Java toolbox. It is generally accepted that errors, or unrecoverable events, should be dealt with using unchecked exceptions and that recoverable problems, or contingencies, should be dealt with using checked exceptions.

However, there is another option for dealing with recoverable problems, i.e. using return values.

null/false/-1

At its most simple, using a return value to signal a problem would involve returning a null value instead of an actual object to signify that an object could not be returned (or retrieved, or created depending on the context) for some reason.
For example, this is the approach taken by the get(key) method of the Map class in the Collections API.

A slight variation on this when dealing with numeric return types, is to return -1 to signify a problem or some other condition. For example, this is the approach taken by the indexOf() method of the List class in the Collections API.

Another variation is having a boolean return type, with a return of true representing that the operation took place OK, and false representing that the operation could not be completed, for whatever reason. For example, this is the approach taken by the offer() method of the Queue class in the Collections API.

Integer return codes – no!

A more complicated (but not recommended!) approach (typically, only really an option if the return type is numeric), is to use specific values (e.g. negative) to represent a variety of problem. This approach however, is definitely not recommended as you are:

• severely limited by the existing return type of the method
• essentially hijacking the return type to use it for error handling
• getting into the realm of C/C++ error code checking, something Java exceptions were created to avoid

Special Result Class

Another better, but still fairly unorthodox, approach is to use a Special Result Class. A Special Result Class is a class whose sole purpose is to enable result and/or error data to be returned in a single return type.
For example, a getUser() method could have a GetUserResult as its return type, where GetUserResult has a boolean returning hasErrors() method that can be checked to see if all went well. If so, the calling code can call getResult() which returns the valid result (i.e. the return type you would normally expect the getUser method to return). If not, the calling code can call getErrors() and deal with the returned errors.

Advantages

The advantages of using a Special Result Class a a return type are:
1. They replace the need for checked exceptions

Avoiding checked exceptions, and their associated infrastructure overhead of try/catches, keeps your code much simpler and easier to use.

2. You are not forced to deal with errors.

You can ignore them if you simply don’t care about them, or if you are sure the call will succeed, avoiding redundant code such as

try {
…
} catch (Exception ex) {
//no action required…
}

3. Multiple errors = single return value
In the case of a large number of possible errors being generated, you still deal with a single return object, rather than having a large number of exceptions thrown and declared in the method signature

Disadvantages

The disadvantages of the Special Result Class approach are:
1. Explicit check required

The caller has to explicitly check the return value if they are concerned about errors happening (whereas Exceptions are ‘automatically’ thrown)

2. Checking for errors is not enforced by the compiler – it is up to the developer to do so, making it much more likely for errors to go undetected. In general, it is best to detect problems as early as possible.

3. Additional calls necessary

If the return value confirms errors occurred, additional calls are necessary to find the cause of the errors
As with the ‘specific numeric return values to represent errors’ approach above, we are getting back to the approach used for C/C++ error code checking, something Java exceptions were created to avoid

4. Any code that needs to deal with the errors has to have direct access to the special result object

With exceptions, the error/exception can be propagated up through the call stack to the code that is most suitable to deal with it (e.g. in a fault layer; a layer in an application dedicated to dealing with faults, as described here). A special result object however is more difficult to pass up through a call stack as it would mean changing the return type of all methods involved. Passing the special result object around to different methods as a parameter is also a little messy.

5. More unorthodox than exceptions
Exceptions are normal classes, can have their own methods, fields etc, which can contain info to describe the situation that caused the exception to be thrown. A Special Result Class may be setup with the same capabilities, but its use is likely to be less intuitive to most developers.