| Summary: | Strange insertion for quick fix on code with syntax errors | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | John Arthorne <john.arthorne> |
| Component: | Core | Assignee: | David Audel <david_audel> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | martinae, Tod_Creasey |
| Version: | 3.3 | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | stalebug | ||
The recovery ends 'test' wity the bracket, and defines 'IOException e' as a new field. The quick fix then inserts before the new field. As you don't even have a 'try' block, this is pretty hard, I think. Moving to jdt.core, maybe they have a good idea. But I tend to say that this is too special to spend too much energy on. Is this is Vista specific problem? This is not a Vista specific problem. Fix the recovery problem would require deep change in our recovery strategy.
In this test case there is no syntax error inside the method.
public void test() {
InputStream stream = createStream();
stream.read();
}
We should recover parts of statements during the 'diet' parse. Currently we only recover types, fields, methods and local variables declaration. So it would require too add a kind of statements recovery in our 'diet' parse.
I am agree with Martin, this would require too much energy and could add more problems than fixed problems.
I understand that perfect recovery is probaby impossible in this case. It does seems strange to me that given this line:
catch (IOException e) {
It interprets this as a field declaration, even though it is surrounded by brackets, has no semi-colon, and is followed by a brace. Perhaps the recovery is already trying to be too smart here?
I don't really know much about syntax recovery, so feel free to close if this case isn't worth the effort.
I will look if we can simply avoid to build this field. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
Build: I20061108-0800 I had this code with unmatched braces (missing try): public class A { public void test() { InputStream stream = createStream(); stream.read(); } catch (IOException e) { e.printStackTrace(); } } } I put the cursor over the createStream() and invoked the "Create method createStream()" quick fix. I end up with this code: public class A { public void test() { InputStream stream = createStream(); stream.read(); } catch (private InputStream createStream() { return null; } IOException e) { e.printStackTrace(); } } } The insertion point inside the catch statement is strange. I wonder if it would be possible to be smarter here... Either detect the mismatched brace and insert the method below the declaration of test(), or open a dialog saying the quick fix cannot be performed because the code is malformed. At the least it should be inserting the method at the beginning of a new line instead of the middle of an existing line of code.