Providing unchecked exception "wrapper" interfaces for an API with checked exceptions

Question

I recently had a discussion in the forum of an API, because they changed an exception from checked to unchecked. I believed it needs to be checked, because it is recoverable. The arguments of "the other side" were verbosity and tediousness of try/catch or throws.

If it were purely theoretical question, I'd be right, but I agree that in practice it is sometimes tedious to write all these try/catches just for the sake of rethrowing unchecked exceptions, or logging.

So, an idea came to my mind, and I wonder whether it's viable. I'll illustrate with simple code:

public interface Foo {
    String foo() throws Exception;
}

public interface EasyFoo extends Foo {
    String foo();
}

These are two interfaces that define the same method (and this is enforced by inheritance), but the "easy" version does not define throwing checked exceptions. Then come 2 default implementations:

public class FooImpl implements Foo {

    @Override
    public String foo() throws Exception {
        return "foo";
    }
}

public class EasyFooImpl implements EasyFoo {

    Foo foo;

    public EasyFooImpl(Foo foo) {
        this.foo = foo;
    }

    @Override
    public String foo() {
        try {
            return foo.foo();
        } catch (Exception ex) {
            throw new RuntimeException(ex);
        }
    }
}

The latter delegates to the former, wrapping all exceptions in runtime exceptions.

And finally a factory:

public class FooFactory {
    public static Foo createFoo() {
        return new FooImpl();
    }

    public static EasyFoo createEasyFoo() {
        return new EasyFooImpl(new FooImpl());
    }
}

The benefits:

• the user of the API can choose how he likes to use the implementation. If he doesn't intend to do anything with the checked exceptions, he can use the "easy" version
• you support only one interface. The 2nd is the same, and you'll just have to add the methods that you have in the main one.

• the user can use the EasyFoo in places where Foo is required:

  EasyFoo foo = FooFactory.createEasyFoo();
  helper.doSomething(foo); // which is public void doSomething(Foo foo);
  

Enough foos - the question is, is this a viable solution that can reduce verbosity while retaining the good sides of checked exceptions?

Answer 1

Just accept the fact that the exception is unchecked and move on.

The industry is moving away from checked exceptions: C++ never had them, C# decided not to follow Java in this place, and the latest frameworks for Java are using unchecked exceptions.

Face it, checked exceptions are a nice idea that doesn't work in practice.

As a result, the thing you try in your code, will never pass any code review I'll be part of.

Answer 2

Ok, I'm going to assume that this is a honest-to-goodness exceptional case, that is extremely unlikely to happen. It isn't like java.sql, that throws an exception when opening a connection fails, which can happen very easily and should be handled by returning null.

If there are people who want this exception unchecked, they should write their own wrapper for it, IMO. If you did want it in the library, though, I'd do it exactly as you did for interfaces. The unchecked version doesn't depend on the checked vesion's implementation, so you only ever need one wrapper EasyFooImpl.

I would wonder about the design of the library if I ever saw that. Checked or unchecked, it's best to avoid throwing exceptions altogether. There are only two valid reasons I see as being "exception-worthy":

• Where an unknown operation leaves the code in a unknown/invalid state. This should unrecoverable by the code that throws the exception.
• Where it is impossible to return an invalid state, such as null or 0. An example that comes to mind is Integer.parse(). You can't return null; it requires int. And you can't return 0 or NAN because that is in the valid return set of the method. An exception the cleanest, most readable way you can signal that the string is unparsable to an integer.

Answer 3

Just to add in conversation:

IMHO Checked Exception are included for a reason. A method with a reasonable chance of failure should throw a checked Exception. e.g. IO classes rely on IO Devices which might not available at the time and thus throw a checked exception, IOException. The benefit of declaring IOException as checked is that Java enforces providing error handling or alternative solution. This is not enforced in the case of exceptions derived from RuntimeException. IMHO this enforcement encourages coders to write robust code which is better then not having an extra throws clause.

Answer 4

If I had to do anything like that I'd just use java.lang.reflect.Proxy and generate the wrappers on the fly. You an check if the methods of Foo and EasyFoo are matching properly and disallow the EasyFoo impl (both interfaces should have the same method signatures but EasyFoo, no declared exceptions). In the end you have a reusable library to do dirty stuff. The invocation through the proxy will be slower but who cares.

So basically you need one class the generates proxies and one designated exception for the wrapping. You should wrap exceptions that are declared only.

Overall the code is synthetic sugar to me, though. You can always live w/ throws declaration instead. Even possible, I guess altering the compiler is not very feasible but the runtime verifier doesn't care of the exception declarations.

Answer 5

Best practice in exception-handling is to "throw early, catch late".

Exceptions should mostly be handled at the business/ or request level -- it makes absolute sense to reconnect to an external system/ or resend a failed request. It generally does not make sense to retry a single byte, or a single SQL query.

Given that, the concept of checked exceptions -- forcing you to "handle immediately" or declare -- is of limited use.

Originally they were intended for contingencies, as opposed to failures. For example, an InsufficientFundsException when making a payment. Their spread to instead be used for all kinds of unrecoverable low-level systemic failures was largely a mistake.

You should design API insteads to use runtime exceptions, and (if you need to catch) should rethrow checked as runtime exceptions. In my projects, I declare AppSqlException, AppInternalException, AppConfigException etc which work very well.

See:

• http://literatejava.com/uncategorized/checked-exceptions-javas-biggest-mistake/