Community
Participate
Working Groups
Stable: 20011219 Assume I have the line below & the cursor is at the end of it public BusObj execute(String portName, BusObj busObj) throws Collab If I hit code assist (ctrl+space) it would be preferable that it offers me exceptions beginning with Collab rather than all Collab prefixes classes. (meta: Code assist has been very useful - the above is just an observation for possible enhancement).
The proposal are computed by JDT core, given that code assist is already very good we should make it even better and try to be smarter. FYI in javadoc code assist we are doing the right thing with exceptions: @exception <ctrl space> will show you the list of exceptions thrown by the method.
We have the information that we are looking at an exception, the only problem is that we do not compute the hierarchy of all exception types in order to fill the exception type, but simply do a type name search. Resolving hierarchies for all candidate types would be way overkilling, and inferring thrown exception types isn't easy, given in codeassist mode, we have stripped all the statements already (avoiding thus unnecessary resolutions).
Created attachment 283 [details] Snapshot of code assist for Collab
When I did throws Collab and requested assist I got a reasonablly good number of choices beginning with Collab and the only plausible one was well down the list. see my snapshot attached. I am not sure I 100% follow your argument to pardon my ignorance but it seems as 1) You know the option has to begin with Collab & must be an exception. So I am unclear why this is costly to determine. 2) Even if you can't filter exceptions (not sure I follow why you can't look at exception hierarchy) a good safe bet is that you could bump Collab*Exception to the top of the list because most people name their exceptions with exception in the name so ones matching that pattern could be at the top? Preapologies for my ignorance in not following your analysis.
Here is why it isn't as simple as in VAJ. In VAJ, we were collecting possible exception completions by looking at all defined classes in the proper context, to which we could simply look at their type hierarchy. In Eclipse, type hierarchies are not persisted, and are computed on demand (for UI purpose) against the Java model (sources, i.e. no build state is required). We use our search infrastructure to find all defined classes, since their respective source files got indexed. In order to feed codeassist answers, we do not open each defined class to obtain its source, and then resolve its hierarchy to see if it is an exception. Strictly speaking, this is what would be involved to solve this one as we did in VAJ. Of course performance would be prohibitive. The post filtering with *Exception might work though, and is a trick already used for breakpoint on Exception types. Given sorting is done in the UI, we would need a distinct API callback to feed 'potential' exception types to the UI client (we currently only answer types). An alternative would be to infer the exception types from the code being completed. If inside a catch block, then accumulating all thrown exception types in the body would give us an indication of likely caught ones. This however requires a change in the code assist engine, given we currently flush the statements in the try block for avoiding unnecessary type resolutions (which can cause to load new units/classfiles in the resolution dynamically). Now, one could argue that if the exception type to be caught is a member type, then you potentially need non exception types. class X { class MEx extends Exception {} } how will you use code assist to obtain X.MEx exception type ? You need to be able to complete on X first, which isn't an exception type per se. Member type completions are regular member completions (you need first to get the type right, before getting to a member field/type/method).
To wrap up - bumping the "Exception" ones to the top might be a good quick hack - I would not recommend tossing out all of your current ones for the member reason you give below. In a nutshell, any help here is goodness to the user.
We would need an API change to indicate the UI sorter that it is an exception type completion ?
*** Bug 11651 has been marked as a duplicate of this bug. ***
This may sound stupid, but why not simply iterate through the list of suggested classes, and weed out everything where the class does not implement Throwable? Doing this just before the list is shown should be a linear time algorithm, and the delay probably negligible...
Relevance might help on this front, by recognizing presence of *Exception* or *Error* in type suggestions.
If the proposal is an exception (type name contain 'exception' or 'error') then proposal is more relevant. Fixed.
