Throwing an Exception Not Defined in the Interface

Question

What is the best practice to follow when you need to throw an exception which was not defined in an interface that you are implementing?

Here is an example:

public interface Reader
{
    public abstract void read() throws IOException;
}

public class CarrotReader implements Reader
{
    public void read() throws IOException {}
}

public class CupcakeReader implements Reader
{
    public void read() throws IOException, CupcakeException {}
}

In this case, you have a specific exception that occurs when reading cupcakes, so you want to throw an exception related to this. However, Reader doesn't define this type of exception in its interface, so what do you do? Furthermore, it doesn't make sense to add CupcakeException to the throws clause in the Reader interface, because this type of exception is specific to CupcakeReader. One way around this is to have Reader define read such that it throws some parent type, like Exception, but then you lose the context for the exception. What should you do in this situation? Thanks!

---

Another interesting situation that has been brought up involves an interface over which you have no control. In this case, what is the best way to indicate that a problem has occurred?

For illustrative purposes, here is another example:

public interface Reader
{
    public abstract void read();
}

public class CupcakeReader implements Reader
{
    public void read() throws CupcakeException {}
}

In this case, you cannot change Reader, but you want to indicate that a problem has occurred in CupcakeReader's read method.

Answer 1

Perhaps you could make an abstract ReaderSpecificException class, put it in the Interface, and subclass CupcakeException from this abstract class.

Answer 2

Use something called ReaderException that will serve as the root interface of your exception hierarchy. ReaderException will also provides a link to other exceptions that get thrown due to lower level exceptoins.

Answer 3

You may have to create an exception of the expected type instead.

... catch(CupcakeException e) {
   throw new IOException("The sky is falling", e);
 }

Answer 4

If you create a higher abstract exception that works as a base class for CupCakeException you don't bind the Reader Interface to a specific implementation like you would be doing if you added the CupCakeException to the Reader interface. If you don't let one Exception inherit from another there is a constructor in the exception class that takes a throwable as second argument like Thorbjørn Ravn Andersen allready showed in his short code example. The enables you to generate a more abstract exception and every part of your code that needs to know more then just "there is an error" can look for the cause of the higher exception.

Answer 5

Just don't use checked exceptions.

The example you showed is one of the reasons checked exceptions are bad.

The main reason though is that the user of your cupcake reader will have to handle your exception regardless of whether he is interested in it or not.

So instead of:

Value value = reader.read();

You are forcing him to do this:

Value value = null;
try {
    value = reader.read();
} catch (Exception e) {
    // now what??
}

value.doSomething();   // potential NPE here

Think which one is better, more readable and less error prone and just stop using checked exceptions.

EDIT:

I am surprised with the negative rating. Are there people who still think that checked exceptions are great? If so here are some references why you shouldn't use checked exceptions:

• No modern framework uses checked exceptions (Spring, EJB3 etc)
• Article with code examples here
• StackOverflow topic
• Effective Java (sections 58 and 59) - here

Answer 6

Exception is part of the interface. Define a generic parent for all your exceptions in the interface if you can redefine the interface.

You can also make CupcakeException a child of IOException.