We Keep Coding

How to wrap checked exceptions but keep the original runtime exceptions in Java

I have some code that might throw both checked and runtime exceptions.
I'd like to catch the checked exception and wrap it with a runtime exception. But if a RuntimeException is thrown, I don't have to wrap it as it's already a runtime exception.
The solution I have has a bit overhead and isn't "neat":
try {
// some code that can throw both checked and runtime exception
} catch (RuntimeException e) {
throw e;
} catch (Exception e) {
throw new RuntimeException(e);
}
Any idea for a more elegant way?

I use a "blind" rethrow to pass up checked exceptions. I have used this for passing through the Streams API where I can't use lambdas which throw checked exceptions. e.g We have ThrowingXxxxx functional interfaces so the checked exception can be passed through.
This allows me to catch the checked exception in a caller naturally without needing to know a callee had to pass it through an interface which didn't allow checked exceptions.
try {
// some code that can throw both checked and runtime exception
} catch (Exception e) {
throw rethrow(e);
}
In a calling method I can declare the checked exception again.
public void loadFile(String file) throws IOException {
// call method with rethrow
}
/**
* Cast a CheckedException as an unchecked one.
*
* #param throwable to cast
* #param <T> the type of the Throwable
* #return this method will never return a Throwable instance, it will just throw it.
* #throws T the throwable as an unchecked throwable
*/
#SuppressWarnings("unchecked")
public static <T extends Throwable> RuntimeException rethrow(Throwable throwable) throws T {
throw (T) throwable; // rely on vacuous cast
}
There is a lot of different options for handling exceptions. We use a few of them.
https://vanilla-java.github.io/2016/06/21/Reviewing-Exception-Handling.html

Guava's Throwables.propagate() does exactly this:
try {
// some code that can throw both checked and runtime exception
} catch (Exception e) {
throw Throwables.propagate(e);
}
UPDATE: This method is now deprecated. See this page for a detailed explanation.

Not really.
If you do this a lot, you could tuck it away into a helper method.
static RuntimeException unchecked(Throwable t){
if (t instanceof RuntimeException){
return (RuntimeException) t;
} else if (t instanceof Error) { // if you don't want to wrap those
throw (Error) t;
} else {
return new RuntimeException(t);
}
}
try{
// ..
}
catch (Exception e){
throw unchecked(e);
}

I have a specially compiled .class file containing the following:
public class Thrower {
public static void Throw(java.lang.Throwable t) {
throw t;
}
}
It just works. The java compiler would normally refuse to compile this, but the bytecode verifier doesn't care at all.
The class is used similar to Peter Lawrey's answer:
try {
// some code that can throw both checked and runtime exception
} catch (Exception e) {
Thrower.Throw(e);
}

You can rewrite the same using instanceof operator
try {
// some code that can throw both checked and runtime exception
} catch (Exception e) {
if (e instanceof RuntimeException) {
throw e;
} else {
throw new RuntimeException(e);
}
}
However, your solution looks better.

The problem is that Exception is too broad. You should know exactly what the possible checked exceptions are.
try {
// code that throws checked and unchecked exceptions
} catch (IOException | SomeOtherException ex) {
throw new RuntimeException(ex);
}
The reasons why this wouldn't work reveal deeper problems that should be addressed instead:
If a method declares that it throws Exception then it is being too broad. Knowing that "something can go wrong" with no further information is of no use to a caller. The method should be using specific exception classes in a meaningful hierarchy, or using unchecked exceptions if appropriate.
If a method throws too many different kinds of checked exception then it is too complicated. It should either be refactored into multiple simpler methods, or the exceptions should be arranged in a sensible inheritance hierarchy, depending on the situation.
Of course there can be exceptions to the rule. Declaring a method throws Exception can be perfectly reasonable if it's consumed by some kind of cross-cutting framework (such as JUnit or AspectJ or Spring) rather than comprising an API for others to use.

I generally use the same type of code structure, but condense it down to one line in one of the few times a ternary operator actually makes code better:
try {
// code that can throw
}
catch (Exception e) {
throw (e instanceof RuntimeException) ? (RuntimeException) e : new RuntimeException(e);
}
This does not require additional methods or catch blocks which is why I like it.

lombok has this handled with a simple annotation on the method 😊
Example:
import lombok.SneakyThrows;
#SneakyThrows
void methodThatUsusallyNeedsToDeclareException() {
new FileInputStream("/doesn'tMatter");
}
In the example the method should have declared throws FileNotFoundException, but with the #SneakyThrows annotation, it doesn't.
What actually happens behind the scenes is that lombok does the same trick as the high rated answer to this same question.
Mission accomplished!

Is it useful to declare parent and child exceptions in the same throws clause?

I know that the code below does make sense:
try { ... }
catch (FileNotFoundException exc) { ... }
catch (IOException exc) { ... }
But does declaring those parent and child exceptions in the throws clause make sense?
Suppose I have the following code:
public void doSomething() throws FileNotFoundException, IOException { ... }
We all know that FileNotFoundException is a subclass of IOException. Now does it make sense in any way (readability, performance, et cetera) to declare it like that, opposing to just this:
public void doSomething() throws IOException { ... }

For the Java compiler, it doesn't matter whether a subclass is in the throws clause, because the superclass exception will cover it.
However, for documentation purposes it is important. The caller of your method may want to know that it can throw a subclass exception, e.g. FileNotFoundException, and handle it differently.
try {
doSomething();
}
catch (FileNotFoundException e) {
System.out.println("File not found!");
}
catch (IOException e) {
System.out.println("An I/O error has occurred: " + e.getMessage());
}

Sometimes it makes sense to catch both exceptions, as long the the sub-class exception is specified first (otherwise, I think it won't even compile). It allows you to handle specific exceptions you care about in a different way than more general exceptions.
For example, I have code that reads from a socket. It's a blocking read, an I set a timeout, since there might be nothing to read. That's why I catch SocketTimeoutException and do nothing about it. If, on the other hand, I get other IOExceptions (IOException being an indirect super-class of SocketTimeoutException), I am throwing an exception, since a real failure happened while trying to read from the socket.
catch (SocketTimeoutException ignEx) {
// -- ignore exception, as we are expecting timeout exceptions because
// -- there might be nothing to read
}
catch (IOException ioEx) {
throw new SomeException (...);
}
As for declaring both in the method signature, It is not necessary to declare both in the throws clause, but it would be useful to the users of your method if you document both exceptions in the JavaDoc comments, and describe the conditions in which each of them are thrown.

Throw exception form override method without exception defined on org method interface

I'm extending the class RecordingCommand from org.eclipse.emf.transaction.RecordingCommand; I need to override protected method doExecute(), the method definition does not contain any exception to throw but there is option that inside my code I have and exception and I want to catch it and raise it up, how should I handle this kind of exception, here I throw the message e but I'm not sure that this is the right way to do that.
I hope you will understand the issue since I think it more sophisticated that just throw E
i.e.throw the exception
#Override
protected void doExecute() {
try {
//my logic
} catch(Exception e) {
throw e;
}
}

You can always throw an UncheckedException from a method, which need not be declared in the throws clause.
So, you wrap your exception in any unchecked exception like that extends RuntimeException or even RuntimeException itself.
try {
//my logic
} catch(Exception e) {
throw new RuntimeException(e);
}
And just for the sake of completeness, it is a bad idea to have a single catch block for Exception, which will catch all the exceptions. Rather you should have catch block for specific type of exception your method may throw.

How to propagate the try catch block for Checked Exceptions?

I have basic doubt in Java Exceptions
i.e., All checked exceptions extends from Exception class and Unchecked Exceptions extend from RuntimeException. But Runtime Exception also extends from Exception.
But why to propagate try... catch block with checked Exceptions but not in Unchecked Exceptions?

In general, you should add different catch blocks for each specific type of exception you intend to handle. If you're trying to handle (by rethrowing) checked exceptions, then you should know which type of exceptions to rethrow -- just add a catch block to rethrow each of those exception types.

I think you are asking, "How can I catch Exception but not RuntimeException ?
You probably should not be trying to do that. You should catch specific types of exceptions when possible. If you need to handle all errors, then you should catch Exception and that catches everything.*
You would rarely want to do catch (NullPointerException) because if you ever know that you can have a null then you should check for it. If your code is causing NullPointerException or ArrayOutOfBoundsException then you should fix the code so that it no longer throws those.
This code should show you how to do what you asked about:
public static void throwSomething(Exception throwMe)
{
try {
throw throwMe;
}
catch(Exception ex) {
// Check if the object is a RuntimeException
if(ex instanceof RuntimeException) {
// Throw the same object again.
// Cast to RuntimeException so the compiler will not
// require "throws Exception" on this method.
throw (RuntimeException) ex;
}
System.out.println("Caught an instance of a " +
ex.getClass().toString());
}
}
*Actually, catch(Throwable) will catch everything including Errors.

The easiest way is this:
try {
//do stuff
} catch(RuntimeException e) {
throw e;
} catch(SpecificCheckedException e) {
//handle
} catch(Exception e) {
//handle
}

throw exception

Why can't you throw an InterruptedException in the following way:
try {
System.in.wait(5) //Just an example
} catch (InterruptedException exception) {
exception.printStackTrace();
//On this next line I am confused as to why it will not let me throw the exception
throw exception;
}
I went to http://java24hours.com, but it didn't tell me why I couldn't throw an InterruptedException.
If anyone knows why, PLEASE tell me! I'm desperate! :S

You can only throw it if the method you're writing declares that it throws InterruptedException (or a base class).
For example:
public void valid() throws InterruptedException {
try {
System.in.wait(5) //Just an example
} catch (InterruptedException exception) {
exception.printStackTrace();
throw exception;
}
}
// Note the lack of a "throws" clause.
public void invalid() {
try {
System.in.wait(5) //Just an example
} catch (InterruptedException exception) {
exception.printStackTrace();
throw exception;
}
}
You should read up on checked exceptions for more details.
(Having said this, calling wait() on System.in almost certainly isn't doing what you expect it to...)

There are two kinds of exceptions in Java: checked and unchecked exceptions.
For checked exceptions, the compiler checks if your program handles them, either by catching them or by specifying (with a throws clause) that the method in which the exception might happen, that the method might throw that kind of exception.
Exception classes that are subclasses of java.lang.RuntimeException (and RuntimeException itself) are unchecked exceptions. For those exceptions, the compiler doesn't do the check - so you are not required to catch them or to specify that you might throw them.
Class InterruptedException is a checked exception, so you must either catch it or declare that your method might throw it. You are throwing the exception from the catch block, so you must specify that your method might throw it:
public void invalid() throws InterruptedException {
// ...
Exception classes that extend java.lang.Exception (except RuntimeException and subclasses) are checked exceptions.
See Sun's Java Tutorial about exceptions for detailed information.

InterruptedException is not a RuntimeException so it must be caught or checked (with a throws clause on the method signature). You can only throw a RuntimeException and not be forced by the compiler to catch it.