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

[laeubi]

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