Question

I am a c++ developer and I am pretty new with the checked and unchecked exception in java. The exception specifications in c++ are simply not good and that’s why nobody is using it. I like the checked exception and I have a question, let’s have this interface:

public interface Warehouse {
   MyStuff fetch(int id);
}

The warehouse can be implemented in different way: file, database or in memory (mock object for test).

Now, if I want to implement using a file, I cannot try to open the file in the method otherwise my signature will change and my class will not implement the interface anymore. Also if I had another class with another checked exception all the other existing implementation will be affected.

I can see two solutions:

1. Catch the checked exception and throw another custom runtime exception. I don’t think this is a good solution, why the user should catch a runtime exception saying that a file is missing when there is already a standard and checked way to do that.

2. Do the entire job in the constructor of the implementation class and leave the fetch function unable to throw. I like this way, the object both exists and is valid or it doesn’t exist. The only drawback on this approach is that we cannot implement a lazy evaluation; we need to read and parse the file in the constructor even though nobody will use the object. This is not efficient.

Am I missing something? Is there a better way to avoid this problem?

Answer 1

Your first solution is the right one. Change your interface to :

public interface Warehouse {
    MyStuff fetch(int id) throws FetchFailureException;
}

And make every subclass wrap its IO, JDBC or whatever exception inside a FetchFailureException. This FetchFailureException exception should be runtime if unrecoverable, and checked if recoverable.