I can’t get no satisfaction, I can’t get no satisfaction
‘Cause I try and I try and I try and I try

(I Can’t Get No) Satisfaction – The Rolling Stones

Checked vs. Unchecked Exceptions

It’s a controversial subject; searching Google for checked versus unchecked exceptions reveals a lot of heated discussions both for and against Checked Exceptions.
Charles Lowell has a particularly succinct (and possibly NSFW) view

My view is similar. I can almost see a situation where I would like to ensure that exceptions are dealt with in a certain way, but it doesn’t quite reach as far as using checked exceptions.

Noisy IDEs

I think my issue is largely to do with the way that the IDEs (and compilers) deal with checked exceptions.
In Eclipse, if a method throws a checked exception, then auto-fix suggests two options; “Surround with try/catch” and “Add throws declaration to method”
I particularly have a problem with the second one. The further you get away from the source of the exception, the less likely you are to deal with it in a useful way. Not dealing with the exception is a reasonable option, but why does everyone in the call chain need to know about an exception that someone in the lower levels didn’t care enough about to handle?
Using unchecked exceptions gives us the choice to handle or propagate the exception, without polluting the higher levels with knowledge of unhandled exceptions.

The default Eclipse template for try / catch is to catch the exception and print the stack trace. This isn’t really handling the exception, it’s ignoring it (even if we’ve logged it). There is no way to know if this is an acceptable default without understanding the underlying code. Unfortunately, if we are leaving it as the default we probably don’t understand the underlying code (yet).

An alternative to Checked Exceptions
One of the nice things about checked exceptions is that they let you know the types of exception you can get. You get the IDE auto-completion and compiler checking.
A checked exception is essentially saying, “You might get this exception, and I insist that you deal with it in the way that you feel is most appropriate”
How can we continue to do this, and at the same time prevent boiler-plate or unnecessary pollution?

Something that I’m thinking about (but haven’t had the need to implement yet), is the concept of an ExceptionHandler class. This is an ideal place for Java Generics to come into play.
For example:

public void someCodeThatMayThrowAFileNotFoundException(String fileName, ExceptionHandler<FileNotFoundException> exceptionHandler) {
try {
open(fileName); // throws FileNotFoundException
}
catch (FileNotFoundException e) {
exceptionHandler.handleException(e);
}
}


By coding in this way, we can provide sensible default actions, such as:

public class LogAndIgnoreExceptionHandler extends ExceptionHandler<T extends Exception> {
public void handleException(T exception) {
exception.printStackTrace(); // or log4j equivalent
}
}


This reduces the try / catch noise, gives us the compiler checking and type completion, and explicitly details the strategy that we are using for handling the exceptions for this part of code.

I’m open to someone showing me a really good use of checked exceptions, but for the time being, I won’t be using them.

Antony Marcano and I have just started running a coding design workshop. Most of the audience are new to coding and we are trying to focus on good habits that are applicable across all programming languages.
In our first session, we created a vending machine. By the end of 90 minutes, it was able to dispense a drink as long as it had sufficient money and stock available.
One of the questions that we asked was “What do we do when the customer has not inserted enough money and we press the button for the drink?”
Some of the people who had some programming background said “Return null”, which is what brings us to this post.

Good Citizen

In the wiki for the PicoContainer project, there is a page titled “Good Citizen“, which details a number of good practices that all Java classes would benefit from trying to adhere to.
The practices make a lot of sense when you think about them, but they aren’t really explained. I’m going to try and address that issue as we cover them in the workshop.
The practice that we are looking at today is “Never expect or return null”, with a dash of “Fail Fast” for flavour.

What’s so bad about null?

In the Java world, when we declare a method signature, we specify a return type. In the case of our vending machine we had:

public Drink giveMeADrink() {...}

By declaring that the return type is Drink, we are signing up to return something that “is-a” drink.
We could also return null, which is a nothing value. We could use this to represent that you did not get a drink.
The client code may look something like this:

myVendingMachine.giveMeADrink().downInOne();

If we return null, this code will fail with a NullPointerException. Not particularly useful, but at least we are using the result straight away. The problems become much worse if we store the returned Drink for use later.
When we said we will always return a Drink, we lied.

Programming Defensively

The sample client code above makes the assumption that the result of giveMeADrink will be a Drink. Given that we’ve actually signed up to that contract, that doesn’t seem to be unreasonable. But now the client code is broken and they have an angry customer, they are going to have to work around the issue. It would probably look like this:

Drink myDrink = myVendingMachine.giveMeADrink();
if(myDrink != null) {
myDrink.downInOne();
}

This code is actually saying “I’ve asked you to give me a drink, but I don’t trust you, so I will check first”.

Why isn’t this working? An Exceptional Approach

If we rely on our client to check that they received a valid result, we lose out on an opportunity to let the client know why the call was unsuccessful.
In the Programming Defensively example, we can recover from being returned a null, but we don’t know why it was null. Was it because we hadn’t inserted the money? Was it because the machine was out of stock? Was it because the stars were out of alignment?
Do we handle the scenarios differently? If we haven’t inserted enough money, that’s something we can deal with, but if the machine is empty, we need to look for another machine.

What if our code looked like this?

public Drink giveMeADrink() {
if(weDontHaveEnoughMoney()) {throw new NotEnoughMoneyException();}
if(weDontHaveEnoughStock()) {throw new DrinkOutOfStockException();}
return new Drink();
}

What we have said is “We will always give you a drink or tell you why we couldn’t“

Now when we attempt to call giveMeADrink, it lets us know straight away if it can’t proceed. It also gives us a good indication of why it is having problems.
The client code calls:

myVendingMachine.giveMeADrink().downInOne();

and gets told “Sorry, I’d give you a drink, but you didn’t insert enough money“.
Our code is being honest, polite and giving the client an opportunity to remedy the situation. The customer is still angry, but now he’s angry with himself for not putting in enough money.

In Summary

• Programming defensively is programming distrustfully
• Returning null is dishonest. It requires others to check that we’ve upheld our side of the bargain
• Throwing a meaningful exception allows us to let the caller know why their call did not succeed

The thing that bothers me a lot more though, is the fact that everyone else is forced to know about your singleton-ness..

ImASingleton.getInstance().doSomething();

*shivers*

If you have to store global state, it would be nice if we could hide that from the clients. Why do we have a single instance with instance variables accessed through a static getInstance method, when we could hide (ooh, encapsulation) the implementation behind multiple instances with private static variables?
By using instance methods, we also get all the interface / testing / mocking goodness.

new ImASingletonButYouCantTell().doSomething();

OK, I’m rambling… am I missing something? (please rant below)

Most people were saying that there is no harm in having static methods in utility classes, and this is one place where I would disagree.
The example used was the java.lang.Math class with it’s utility methods.

java.lang.Math is non-instantiable, you can only access it’s utility methods through static calls.
For the most part, this is fine, but take the example of Math.sqrt(x)
This method returns NaN if x is < 0. For the majority of cases this is fine, but if I start working with complex numbers, then this is no longer the ideal behaviour.
Admittedly, in this case I would not want the return value to be a double, but I may want it to throw a ComplexNumberException or something similar. If I have used the static method throughout my code, I now have to go and update every single reference to the concrete class. What a pain in the class!

However, if I had used a utility class with instance methods, I could have injected the utility class in the constructor and I could now change it out for my new ComplexMathUtility class through configuration / DI.

This isn’t the best example, as the required return types are different, but think of a String utility class, perhaps something that formats a header for a report.
We could (naively) implement this using static utility methods. If we later require two different types of report heading, this is going to make our life difficult.
If we implement this using an instantiable ReportFormatter, we can swap in new ones at runtime / configuration. We’ve just implemented a ReportFormatterStrategy

My feeling is that implementing utilities as instance methods keeps the design flexible and allows for more code reuse as things naturally gravitate towards smaller, more easily testable, logically grouped units of functionality…
Or am I just dreaming?