What issues may ensue by throwing a checked exception as a RuntimeException?

Question

I have a piece of code that encodes some kind of business data in a JSON string:

public String encodeDataAsJsonString(Data data) throws JSONException {
    JSONObject o = new JSONObject();
    o.put("SomeField1", data.getSomeProperty1());
    o.put("SomeField2", data.getSomeProperty2());
    ...
    return o;
}

The thing is:

• JSONException is a checked exception, but
• I don't really know how to handle it at compile time. If a JSONException really occurs, it's probably a bug in the the code and should be handled by the regular "global uncaught exception handler" which is already there (e.g. this), and which already performs all the necessary logging and cleaning up.

Thus, I ended up doing this in the calling method:

...
try {
    encoded = encodeDataAsJsonString(data);
} catch (JSONException e) {
    throw new RuntimeException(e);
}
...

It seemed like a lesser evil than adding a throws JSONException to every method up the call stack. However, it still feels dirty, hence my question:

If I want some specific checked exception to go the "regular unchecked exception route", is rethrowing it as a RuntimeException the correct idiom to use?

Answer 1

The situation is quite simple: if your exception has no business value, that is, it is just a failure, definitely use an unchecked exception. If you need to handle the exception in a way specific to that exception, which in most cases means that the handling code will involve business logic, then it is still OK to use an unchecked exception, but there are at least some benefits in using a checked exception. However, in either case the raw exception you get from the JSON API is useless and it is only a sign of bad public API design.

As a side note, there's the "sneaky throw" idiom which will allow you to throw your original checked exception without wrapping:

public static <R> R sneakyThrow(Throwable t) {
  return UncheckedThrower.<RuntimeException, R>sneakyThrow0(t);
}
@SuppressWarnings("unchecked")
private static <E extends Exception, R> R sneakyThrow0(Throwable t) throws E { throw (E)t; }

Needless to say, you should be very careful about using this approach in a project.

Answer 2

Short answer, yes.

You could probably create your own exception class (a child of runtime exception) and re throw that to make it easier to document, catch/ handle it where necessary. Something like hibernate does by using HibernateException, client/ calling code is not forced to catch it but can always catch it when something logical/ application specific can be done with it.

Answer 3

Well, if you don't intend to handled the exception in you application code then you can throw it as RuntimeException.

I prefer to use com.google.common.base.Throwables to propagate this.