Community
Participate
Working Groups
3.1 M2 This may be hard, but anyway... Consider this fragment of code: try { FileOutputStream output= new FileOutputStream(file); // throws FNFEx output.close(); // throws IOEx } catch (FileNotFoundException e) { // error opening file } catch (IOException e) { // error closing file } The only exception thrown by the first statement is FileNotFoundException, which is caught by the first catch block. When putting the caret on 'IOException', the first statement gets still highlighted, even though it is not a valid path. An implementation of this feature request would have to analyze the other catch blocks and check the type hierarchies for subclasses...
On one side it's a cool feature on the other side it hides information.
Another, more common example: InputStream stream= ... try { ... = stream.read(); try { stream.close(); } catch (IOException exception) { } } catch (IOException exception) { } Selecting the last occurrence of IOException should not highlight "stream.close ()".
(In reply to comment #2) > Another, more common example: That's a different bug, see bug 68305. (In reply to comment #0) > This may be hard, [..] Not too hard, since the ExceptionOccurrencesFinder already has an AST with bindings and does not need to create type hierarchies, etc.
Today I also came across that behaviour in Eclipse v.3.7.2. First I was a little bit confused and thought the mistake was on my side. But then I discovered that Eclipse doesn't care for exceptions which are caught by another catch block of the same try block. (In reply to Dani Megert from comment #1) > On one side it's a cool feature on the other side it hides information. I agree to that. But it would be nice to implement that depending on your configuration. The default behaviour would be like it is now. But clicking on a check-box in the Eclipse preference could change that behaviour to the one mentioned by Tom Hofmann.
