Seemingly puzzling exception handling behavior that appears sensitive to try block content

[laeubi]

I'm not sure this is a new behavior and actually a feature, but has created some confusion on my side and I can't remember to have such thing in the past.

Eclipse SDK

Version: 2025-03 (4.35)
Build id: I20241203-1800

Consider the following code snippet:

public static void main(String[] args) {
	try {
		//throw new Exception();
		//new FileOutputStream("");
	} catch(Exception e) {
		throw e;
	}
}

this code compiles without any error or warning!

Now comment in the first line

public static void main(String[] args) {
	try {
		throw new Exception();
		//new FileOutputStream("");
	} catch(Exception e) {
		throw e;
	}
}

this results in what I have expsected in the first place

now use the second line:

public static void main(String[] args) {
	try {
		//throw new Exception();
		new FileOutputStream("");
	} catch(Exception e) {
		throw e;
	}
}

this gives a little different hint:

and even if it talks about FileNotFoundException, if I apply the quickfix I get this

public static void main(String[] args) throws Exception {
	try {
		//throw new Exception();
		new FileOutputStream("");
	} catch(Exception e) {
		throw e;
	}
}

[srikanth-sankaran]

Perhaps the title should read " ... depending on try block content ..." ??

Please always provide proper code with imports, class headers and such 😧 - Thanks!

ECJ behavior compares well with Javac 23 😄

Compilers actually track what exceptions may be raised by the try block, so can speak of "sharper" types -- that explains the puzzle.

I would say there is some mild surprise with the quick fixed added throws clause, although it is not a correctness issue and perhaps a long standing behavior.

There is some surprise why the catch block wouldn't be warned about in the very first case - but given bother compilers agree there is some arcane provision in the spec that calls for it, I would daresay

In summary, I don't see a defect here.

[jukzi]

FileOutputStream("") can only throw FileNotFoundException so it may be surprising but not an error

[srikanth-sankaran]

I would say there is some mild surprise with the quick fixed added throws clause, although it is not a correctness issue and perhaps a long standing behavior.

Here is my take for a plausible explanation without poking into JDT.UI code:

This is very likely a case of the left hand not knowing what the right is doing. Quick fix is implemented by JDT.UI perhaps by scanning the catch blocks in existence disregarding the _ textual contents_ of the compiler message. I would imagine that JDT.UI only looks at org.eclipse.jdt.core.compiler.IProblem.getID() and gathers that it is a case of org.eclipse.jdt.core.compiler.IProblem.UnhandledException - does its own analysis to compute what throws are missing, in the process moving to a blunter type.

@noopur2507 may be able to confirm.

[srikanth-sankaran]

@jukzi - hope you don't mind, edited the title further to clarify.

[laeubi]

Please always provide proper code with imports, class headers and such 😧 - Thanks!

Sorry for that I just don't wanted to clutter the code and though a simple main class does not leave much problem for any JDT committers :-)

FileOutputStream("") can only throw FileNotFoundException so it may be surprising but not an error

I don't understand this comment, no one said that it is an error, I just used that as an example for a different Exception type thrown by a method.

There is some surprise why the catch block wouldn't be warned about in the very first case - but given bother compilers agree there is some arcane provision in the spec that calls for it, I would daresay

It was jsut very surprising as I edited some old code and suddenly got the message to throw exception but if it is desired I maybe just don't use that pattern often enough to ever have noticed that :-D

[jukzi]

no one said that it is an error

Creating an issue implies the author wants something to change.
converted to discussion as requested.

[laeubi]

@srikanth-sankaran maybe this is better converted to a Q/A discussion then instead of closing the issue.

[srikanth-sankaran]

Sorry for that I just don't wanted to clutter the code and though a simple main class does not leave much problem for any JDT committers :-)

We always prefer full but minimal self standing examples. That would allow copy + paste + save + run javac to compare behavior. And eliminate any and all guesswork and collateral surprises.

[srikanth-sankaran]

OK, consider this program:

import java.io.FileNotFoundException;

public class X {
	public static void main(String[] args) {
		try {
			// throw new Exception();
			// new FileOutputStream("");
		} catch (FileNotFoundException e) {
			throw e;
		} catch (Exception e) {
			throw e;
		}
	}
}   

This is rejected by both javac and ECJ with near identical message about Unreachable catch block for FileNotFoundException. This exception is never thrown from the try statement body

But there is no complaint about the other catch block that catches Exception e -

This is the first mystery - right?

JLS 14.22 Unreachable Statements reads

...
...
• A catch block C is reachable iff both of the following are true:
– Either the type of C's parameter is an unchecked exception type or Exception
or a superclass of Exception, or some expression or throw statement in the
try block is reachable and can throw a checked exception whose type is
assignment compatible (§5.2) with the type of C's parameter. (An expression
is reachable iff the innermost statement containing it is reachable.)
See §15.6 for normal and abrupt completion of expressions.
– There is no earlier catch block A in the try statement such that the type of C's
parameter is the same as, or a subclass of, the type of A's parameter.

So a straightforward conclusion is that JLS mandates catch (Exception e) { throw e; } is reachable but since no checked exception is thrown by the try block (which is completely commented out) any rethrow by the catch block can only be an unchecked exception and so an unhandled exception error is NOT called for.

So I think both mysteries are explained. One by JLS citation and the other by a plausible left hand not knowing right hand's action claim :)

Let me know if you have more questions