Menu
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:
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?
456
Checked exceptions leads to annoying boilerplate code ( try {} catch () {} ). Every time you call a method that throws a checked exception, you have to write the try-catch-statement. The compiler forces us to catch the exception. Often this ends up in a mixing of main logic and error handling.
Difference Between Checked and Unchecked Exceptions in JavaA checked exception is caught at compile time whereas a runtime or unchecked exception is, as it states, at runtime. A checked exception must be handled either by re-throwing or with a try catch block, whereas an unchecked isn't required to be handled.
The Runtime Exception usually shows the programmer's error, rather than the condition a program is expected to deal with. Runtime Exceptions are also used when a condition that can't happen.
If an argument is null , the method might throw a NullPointerException , which is an unchecked exception. Generally speaking, do not throw a RuntimeException or create a subclass of RuntimeException simply because you don't want to be bothered with specifying the exceptions your methods can throw.
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.
112
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.
38
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.
43
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
