When writing unit tests for a method you want to make sure you cover all of the boundary cases and possible inputs. Some inputs will cause the method to throw an exception and you'll want to verify that output.

Exceptions are caught using a try/catch block. You're trying out a bit of code in the try block and if an exception is thrown by a line in the try block, the catch blocks are there to catch certain types of exceptions you are interested in.

There are two types of exceptions: checked and unchecked exceptions. The differences are outlined extremely well by Josh Bloch in his book Effective Java. This book really is a must for any Java programmer and I can't recommend it enough.

Checked exceptions are for expected errors and should be dealt with programmatically. For example, the checked exception FileNotFoundException happens when you try to open a file that cannot be found. You want your code to work around this situation because users can easily enter bogus files or paths. If a function throws a checked exception, it must indicate that in its method header:

public int read(byte[] b) throws IOException

Unchecked exceptions on the other hand are for programming errors and are also called runtime exceptions. All runtime exceptions are subclasses of the RuntimeException class and do not have to be declared in the method headers of methods that throw those exceptions. They also do not have to be (and should not be) explicitly caught by the code that calls the method. Runtime exceptions should be allowed to trickle all the way up to the virtual machine uncaught and terminate the program because they indicate situations that the program is not meant to recover from. So here's a good general rule: unless you are debugging, never catch Exception because you'll catch all of the runtime exceptions too.

As a side note, Eclipse is great at telling you when you need to catch checked exceptions as you edit code. It even knows that subclasses of RuntimeException do not need to be explicitly caught. It's a fairly simple thing but it saves tons of time because you don't realise it oops! at compile time.

Now, one of Bloch's good pieces of advice is "only throw exceptions in exceptional cases". Part of the rationale is that it creates weird flow in your programs, which can be hard to debug (Joel Spolsky wrote a good article on the downsides of exceptions). But the main reason is even simpler: throwing and catching exceptions is a computationally expensive operation and so it should be done rarely.

In tests however, you should catch all exceptions to make sure they are working properly. For example, my code from yesterday called a method with null to make sure a NullPointerException was thrown:

public void testSetupBuilder_Null()
{
   XMLRepository repository = XMLRepository.getInstance();

   fail("Expected NullPointerException");
}

Let's examine the flow. The call we are interested in is repository.setupBuilder(null);, which is surrounded by a try/catch block. If a NullPointerException is thrown by the method call, the flow will go into the catch block and hit the return; call, ending the test method (by default tests pass if no assertions are made). If NullPointerException is not thrown the catch block will be skipped and JUnit's fail() method will be called, which fails that test immediately.

Couldn't the fail() call be in the try block below the call to repository.setupBuilder(null);?

public void testSetupBuilder_Null()
{
   XMLRepository repository = XMLRepository.getInstance();

   //other runtime exceptions are caught by JUnit
}

If an exception isn't thrown the fail() call will be hit. True, but let's say hypothetically for a moment that repository.setupBuilder(); also throws the unchecked exception IllegalArgumentException. If that exception is thrown instead of NullPointerException the test will pass because we're only catching NullPointerException and the fail() is in the try block and is missed. We don't want the test to pass in that situation because the wrong exception was thrown. Having the fail() call at the end of the test method is more comprehensive.

What I wrote before isn't right so I've crossed it out. The Eclipse JUnit plugin will actually catch the thrown IllegalArgumentException and fail the test, not pass it. Depending on the robustness of your unit testing framework this may work as well. Having the fail() call at the end is more explicit but allowing the exception to be thrown outside of the test will let you examine the stack trace, like I do in the next example. Thanks Andrew for correcting me in the comments.

I feel like making this post longer, so let's do another example. Let's say I have a method call that throws a checked exception but I want to verify an unchecked exception. Here's the (admittedly fictitious) method header:

public int read(File f) throws IOException

and the test method for an input of null:

public void testRead_Null() throws IOException
{
   try
   {
      int byte = read(null);
   }
   catch (NullPointerException npe)
   {
      return;
   }

   fail("Expected NullPointerException");
}

Notice that because we're not explicitly catching the checked IOException we have to make our test method throw it. That's OK though because in the event that an IOException occurs instead of NullPointerException the JUnit testing framework will display a proper error message. The JUnit plugin in Eclipse even shows a stack trace for you. So it's actually in your advantage to write the test methods like this when using Eclipse.

But there is another way. You can handle the IOException yourself which takes a bit more work:

public void testRead_Null()
{
   try
   {
      int byte = read(null);
   }
   catch (NullPointerException npe)
   {
      return;
   }
   catch (IOException ioe)
   {
      e.printStackTrace();
   }

   fail("Expected NullPointerException");
}

This will print the stack trace to standard out, and then hit the fail() call at the end. I prefer the other way because it handles the checked exception better with JUnit. It might depend more on your unit testing framework and how robust it is so I've included this alternate way.

I hope this post helps people out. If you have any comments or corrections let me know.

Links:
JUnit FAQ: testing exceptions