Bug 174001 - [assist] Unexpected types are proposed inside catch block
Summary: [assist] Unexpected types are proposed inside catch block
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: 3.3 M6   Edit
Assignee: David Audel CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-02-13 09:31 EST by David Audel CLA
Modified: 2007-03-20 06:47 EDT (History)
1 user (show)

See Also:


Attachments
Proposed fix for the empty token case (3.36 KB, patch)
2007-02-15 10:06 EST, David Audel CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description David Audel CLA 2007-02-13 09:31:56 EST
From Victor Toni in bug 157584 comment 8

----------------------------------------------------
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

                ) {

                }               
        }

}
----------------------------------------------------

ExceptionContentAssist is proposed and it is not an exception.
Comment 1 David Audel CLA 2007-02-13 09:50:24 EST
This problem is caused by the fact that we use a list of type names to compute proposals and compute type hierarchies would be too costly.

The general case would be hard to fix but perhaps the case of the empty token could be improved.
Comment 2 David Audel CLA 2007-02-15 10:06:30 EST
Created attachment 59058 [details]
Proposed fix for the empty token case
Comment 3 David Audel CLA 2007-02-15 10:07:59 EST
When the completion occurs on an empty token it's possible to not propose types which are not exception. This is possible because when the token is empty only a small subset of types are proposed and we have access to resolved informations about these types (bindings).

When the completion token isn't empty we use searchAllTypeName API to find types name because it would be too costly to compute all the resolved informations. So we only have access to type names and don't have access to the types hierarchy.

I will fix the empty token case and will enter a new bug to keep trace of the non empty case.
Comment 4 David Audel CLA 2007-02-15 10:09:10 EST
Released for 3.3M6

Tests updated
  CompletionTests#testCatchClauseExceptionRef08
  CompletionTests#testCompletionMemberType2

Only the empty token case is fixed.
I entered bug 174312 for the not fixed part of the problem
Comment 5 Maxime Daniel CLA 2007-03-20 06:47:50 EDT
Verified for 3.3 M6 using build I20070319-1335.

Since the limitations of the implemented solution are documented and the fup bug 174312 should take care of the additional work that is still needed, I consider that the situation has improved in the realm of the initial test case and that this bug is verified.

Opened bug 178218 for a different problem detected during the verification.