Community
Participate
Working Groups
Since the compiler/IDE knows already about unhandled exceptions it would be nice to use this information for user input: ---------------------------------------------------- package exceptions; import java.io.EOFException; import java.io.FileNotFoundException; import org.xml.sax.SAXException; public class ExceptionContentAssist { public void doSomething() throws FileNotFoundException, EOFException, SAXException{ } public void doSomethingElse() { try { doSomething(); } catch ( // content assist here ) { } } } ---------------------------------------------------- The content assist could show something type hierachy dialog: IOException + FileNotFoundException + EOFException SAXException ---- This dialog should have some intelligence so that depends on already caught exceptions: ---------------------------------------------------- public void doSomethingElse() { try { doSomething(); } catch (IOException ignore){} catch ( // content assist here ) { } } ---------------------------------------------------- should show only (or fill directly) the SAXException.
We won't change the UI interaction but I agree that code assist could be smarter in this case.
(In reply to comment #1) > We won't change the UI interaction but I agree that code assist could be > smarter in this case. > What do you mean by UI interaction? Currently there is no code assist at all for catching exceptions, I've seen it only as a "Quick fix" option (one could say that this is code assist but it's not interactive as I would expect from "real" code assist). Another point I was wondering about is if AST could be extended (or maybe it already has that capability) to report (possible) RuntimeExceptions which could be thrown by specific code lines (maybe with a configurable filter), maybe this should be another bug entry... This information may be useful and is currently not accessible via the "Quick fix" option.
> Currently there is no code assist at all Sure there is, e.g. type "N" or "NPE" and then Ctrl+Space.
(In reply to comment #3) > > Currently there is no code assist at all > Sure there is, e.g. type "N" or "NPE" and then Ctrl+Space. > Maybe "no at all" was a bit over the top. Nonetheless I wouldn't consider it as code assist which is especially for catching exceptions. Writing "Fi" on the line after "// content assist here" and then Ctrl+Space gives me many entries which are not exceptions, e.g. "File" or "Field". It feels more like the "normal" type completion.
Created attachment 57154 [details] Proposed fix
Released for 3.3M5 Tests added CompletionParserTest2#test0167() -> test0171() GenericsCompletionParserTest#test0213() CompletionTests#testCatchClauseExceptionRef01() -> testCatchClauseExceptionRef13 CompletionTests_1_5#test0300() Exceptions that can be thrown in a try block are proposed with an higher relevance that other exception proposals and exceptions that are already caught aren't proposed.
Verified for 3.3 M5 using warm-up build I20070205-0009.
Great. I just checked the newly released 3.3M5 and it helps a lot. When using the content assist in this example I noticed something unexpected, the last entry proposed is "ExceptionContentAssist" which doesn't seem to make sense in the catch block. One additional RFE could be the that sorting of the entries should be "stable": The content assist showed at first: EOFException FileNotFoundException SAXException Exception IOException ExceptionContentAssist and another time (which is better IMHO): SAXException EOFException FileNotFoundException IOException Exception ExceptionContentAssist
After changing the calling method to: public void doSomethingElse() { try { doSomething(); } catch ( SAXException exception) { } catch ( IOException exception ) { } catch ( // content assist here ) { } } I get these suggestions: EOFException FileNotFoundException ExceptionContentAssist which are already covered by the IOException above.
Reply to comment 8 about proposal sorting: The history of previous completion requests is take into account to sort proposals. That's probably why sorting is not "stable". Currently this work as designed. History is computed by JDT/Text, if you think that this behavior isn't correct you could enter a bug against JDT/Text. Reply to comment 8 about ExceptionContentAssist: The proposal of ExceptionContentAssist is a known problem. Our completion engine use a list of type name to compute his proposals (only the name is known). So the hierarchy of types is not known and we don't know if a type name is the name of a subclass of Exception. We could find this hierarchy but this would be to costly and the code assist operation would last several seconds if there is a lot of types. This would be unacceptable. To solve this problem we consider that a type name is an exception type if his name contain 'Exception' or 'Error'. This is not perfect but it give the right result most of the time. I entered the bug 174001 about this problem. Perhaps the case of the empty token completion could be improved. Reply to comment 9: This is also a known problem. This is also caused by the fact that we use only the name of types and compute the hierarchy of types is to costly. I entered the bug 174002 about this problem. Perhaps the case of the empty token completion could be improved. I close this bug as fixed. Please use the bugs that i have open to continue the discussion about these limitations.
