Question

I keep getting stuck conceptually on deciding an Exception-handling structure for my project.

Suppose you have, as an example:

public abstract class Data {    public abstract String read(); } 

And two subclasses FileData, which reads your data from some specified file, and StaticData, which just returns some pre-defined constant data.

Now, upon reading the file, an IOException may be thrown in FileData, but StaticData will never throw. Most style guides recommend propagating an Exception up the call stack until a sufficient amount of context is available to effectively deal with it.

But I don’t really want to add a throws clause to the abstract read() method. Why? Because Data and the complicated machinery using it knows nothing about files, it just knows about Data. Moreover, there may be other Data subclasses (and more of them) that never throw exceptions and deliver data flawlessly.

On the other hand, the IOException is necessary, for if the disk is unreadable (or some such) an error must be thrown. So the only way out that I see is catching the IOException and throwing some RuntimeException in its place.

Is this the correct philosophy?

Answer 1

You’re right.

The exception should be at the same level of abstraction where is used. This is the reason why since java 1.4 Throwable supports exception chaining. There is no point to throw FileNotFoundException for a service that uses a Database for instance, or for a service that is ‘store’ agnostic.

It could be like this:

public abstract class Data {    public abstract String read() throws DataUnavailableException; }  class DataFile extends Data {      public String read() throws DataUnavailableException {         if( !this.file.exits() ) {             throw new DataUnavailableException( 'Cannot read from ', file );          }           try {                ....          } catch( IOException ioe ) {               throw new DataUnavailableException( ioe );          } finally {               ...          }  }   class DataMemory extends Data {      public String read()  {         // Everything is performed in memory. No exception expected.     }  }   class DataWebService extends Data {        public string read() throws DataUnavailableException {            // connect to some internet service            try {               ...            } catch( UnknownHostException uhe ) {               throw new DataUnavailableException( uhe );            }       }  } 

Bear in mind that if you program with inheritance in mind, you should design carefully for the specific scenarios and test implementations with those scenarios. Obviously if it is harder to code an general purpose library, because you don’t know how is it going to be used. But most of the times applications are constrained to an specific domain.

Should your new exception be Runtime or Checked? It depends, the general rule is to throw Runtime for programming errors and checked for recoverable conditions.

If the exception could be avoided by programming correctly ( such as NullPointerException or IndexOutOfBounds ) use Runtime

If the exception is due to some external resource out of control of the programmer ( the network is down for instance ) AND there is something THAT could be done ( Display a message of retry in 5 mins or something ) then a checked exception should be used.

If the exception is out of control of the programmer, but NOTHING can be done, you could use a RuntimeException. For instance, you’re supposed to write to a file, but the file was deleted and you cannot re-create it or re-try then the program should fail ( there is nothing you can do about it ) most likely with a Runtime.

See these two items from Effective Java:

• Use checked exceptions for recoverable conditions and run-time exceptions for programming errors
• Throw exceptions appropriate to the abstraction

I hope this helps.