Catching an Exception and rethrowing it, but it's not an Exception

Question

I stumbled upon code looking something like this:

void run() {
    try {
        doSomething();
    } catch (Exception ex) {
        System.out.println("Error: " + ex);
        throw ex;
    }
}

void doSomething() {
    throw new RuntimeException();
}

This code surprises me because it looks like the run()-method is capable of throwing an Exception, since it catches Exception and then rethrows it, but the method is not declared to throw Exception and apparently doesn't need to be. This code compiles just fine (in Java 11 at least).

My expectation would be that I would have to declare throws Exception in the run()-method.

Extra information

In a similar way, if doSomething is declared to throw IOException then only IOException needs to be declared in the run()-method, even though Exception is caught and rethrown.

void run() throws IOException {
    try {
        doSomething();
    } catch (Exception ex) {
        System.out.println("Error: " + ex);
        throw ex;
    }
}

void doSomething() throws IOException {
    // ... whatever code you may want ...
}

Question

Java usually likes clarity, what is the reason behind this behavior? Has it always been like this? What in the Java Language Specification allows the run() method not need to declare throws Exception in the code snippets above? (If I would add it, IntelliJ warns me that Exception is never thrown).

Bickel

Side note: There's a bunch of questions on Stack Overflow about Java and exceptions, but I was not able to find a similar question to this one. – Bickel

Interesting. What compiler you're using? If it's IDE compiler, then check with javac - I've been running into cases where Eclipse compiler was more lenient. – Tailwind

I can reproduce this behaviour on openjdk-8. Notably compiling with the -source 1.6 flag raises a compilation error as expected. Compiling with source compatibility 7 does not raise the compilation error – Heliograph

seems like compiler is smarter since Java 7 and does more checks on actual exception that could be thrown. – Osmond

This question is not a duplicate and the answer can be found in the link i provided In detail, in Java SE 7 and later, when you declare one or more exception types in a catch clause, and rethrow the exception handled by this catch block, the compiler verifies that the type of the rethrown exception meets the following conditions : 1. 1. The try block is able to throw it. 2. There are no other preceding catch blocks that can handle it. 3. It is a subtype or supertype of one of the catch clause's exception parameters. – Osmond

The currently marked duplicate is definitely relevant, but doesn't provide a detailed enough answer IMO. There's one link to the JLS in the comments to the answer there, besides that no information. – Bickel

@michalk Those links should really be in an answer and not just in a comment. If you provide a better answer to the other one (or this one if it's reopened), I will upvote it. – Bickel

I guess I found a duplicate question which also is a duplicate but will answer your question – Osmond

Possible duplicate of Rethrowing an Exception: Why does the method compile without a throws clause? – Gusty

Answer 1

I have not scan through the JLS as you have asked in your question, so please take this answer with a grain of salt. I wanted to make it a comment, but it would have been too big.

---

I find funny at times, how javac is pretty "smart" in some cases (like in your case), but leaves a lot of other things to be handled later by JIT. In this case, it is just that the compiler "can tell" that only a RuntimeException would be caught. This is obvious, it's the only thing you throw in doSomething. If you slightly change your code to:

void run() {
    try {
        doSomething();
    } catch (Exception ex) {
        Exception ex2 = new Exception();
        System.out.println("Error: " + ex);
        throw ex2;
    }
}

you will see a different behavior, because now javac can tell that there is a new Exception that you are throwing, un-related to the one you caught.

But things are far from ideal, you can "trick" the compiler yet again via:

void run() {
    try {
        doSomething();
    } catch (Exception ex) {
        Exception ex2 = new Exception();
        ex2 = ex;
        System.out.println("Error: " + ex);
        throw ex2;
    }
}

IMO, because of ex2 = ex; it should not fail again, but it does.

Just in case this was compiled with javac 13+33

Mordred

I read in some link that someone provided that if you reassign the caught exception in the catch-block, then the compiler is not able to be smart. I assume something similar applies in this case. The compiler knows that the ex2 exception will be thrown, it was originally created as an Exception but is then reassigned to ex, and therefore the compiler is not able to be smart. – Bickel

@SimonForsberg someone that has a passion for JLS might come and provided the needed quotes to prove this; unfortunately I don't have them. – Mordred

For the record, when I change the catch block to contain a reassignment of the caught exception to itself (ex = ex;), the heuristic is no longer applied. This behaviour seems to be applied for all source levels from 7 through 11 and probably 13 – Heliograph

Have a look at this question which is also a duplicate. This one and the dup of the possible dup explains it and also links to JLS. – Osmond

Answer 2

Exception is the parent of all exceptions, including RuntimeException, which is unchecked and therefore allowed to be thrown from anywhere. The code in question will allow you to manipulate any unchecked exception (catching and re-throwing), using their common parent, which is questionable, but still ok since it produces only unchecked ones. However, as soon as the compiler detects the use of a checked exception (including the Exception itself), the compilation fails.

This compiles and passes:

@Test
public void test() {
  Runnable underTest = new Runnable() {
    @Override
    public void run() {
      try{
        doSomething();
      } catch (Exception e) {
        throw e;
      };
    }

    private void doSomething() {
      throw new RuntimeException("test");
    }
  };
  assertThatThrownBy(underTest::run)
    .isInstanceOf(Exception.class) // RuntimeException.class also ok
    .hasMessage("test");
}

This doesn't compile:

@Test
public void test() {
  Runnable underTest = new Runnable() {
    @Override
    public void run() {
      try{
        doSomething();
      } catch (Exception e) {
        throw e;
      };
    }

    private void doSomething() throws Exception {
      throw new Exception("test");
    }
  };
  assertThatThrownBy(underTest::run)
    .isInstanceOf(Exception.class)
    .hasMessage("test");
}

Lycian

Answer 3

Unchecked exceptions do not need to be declared in a method or constructor's throws clause if they can be thrown by the execution of the method or constructor and propagate outside the method or constructor boundary. RuntimeException is unchecked.

Haeckel

This answer provides no additional information that hasn't already been shown in my question. I already know the difference between checked unchecked exception. – Bickel