Community
Participate
Working Groups
Very old bug. Paste this into Package Explorer: void bug() { try { } } ==> error says: Syntax error, insert "Finally" to complete BlockStatements should be: Syntax error, insert 'finally' to complete block statements
Dani, this is actually a parser error, which happens when parser cannot complete to any rule, and goes into recovery to fetch the closest match. In this example, to reach the closest match the user has to insert finally { } which is given by the rule Finally ::= 'finally' Block Doing so will satisfy the parent rule BlockStatements. The error message picks up the rules from the parser and thats why you see "Finally" and "BlockStataments" This happens in all parse errors, such as for WhileStatement, ForStatement, etc.
(In reply to comment #1) > The error message picks up the rules from the parser I meant from the grammar file java.g
I'm not sure what you try to sell me ;-). The error messages should target a normal user and not require AST knowledge. Clearly, inserting "Finally" is not a good hint since that won't ever compile.
(In reply to comment #3) > I'm not sure what you try to sell me ;-) Well i was just offering an explanation of why you see what you see, and that this is just expected behaviour and not a "typo" ;) Srikanth, what do you think about this?
> this is just expected behaviour and not a "typo" ;) Mmmh, no - it is the *implemented* behavior ;-)
(In reply to comment #5) > > this is just expected behaviour and not a "typo" ;) > Mmmh, no - it is the *implemented* behavior ;-) Apparently, developers and users expect different behavior :) The error is emitted by a part of the compiler that we have only limited control over, because everything works from tables generated by the parser generator. I see two things we could change: The readableName of the rule mentioned by Ayush could be changed to s.t. like "FinallyBlock" to be more consistent with other rules and to indicate that we're not talking about a keyword ("Finally") but more abstractly about a syntax element. Second, I'm not very happy with the quotes in the error message, because these imply that something should be inserted verbatim, which is not the case for any of these message.
This is what javac 1.7 says: Snippet.java:5: error: 'try' without 'catch', 'finally' or resource declarations try { ^ 1 error ==> they show messages that refer to source elements and not internal AST nodes. > Second, I'm not very happy with the quotes in the error message, because > these imply that something should be inserted verbatim Exactly.
(In reply to comment #7) > ==> they show messages that refer to source elements and not internal AST > nodes. At a closer look "Finally" isn't even an invention of the JDT team, but directly taken from the JLS: TryStatement: try Block Catches try Block Catchesopt Finally Catches: CatchClause Catches CatchClause CatchClause: catch ( FormalParameter ) Block Finally: finally Block This is our specification and that's what the error messages refer to. I agree that users could get better help in these messages, but the current state doesn't look like an accident but like a well-considered strategy. Changing anything here in a consistent way will be a major change.
> At a closer look "Finally" isn't even an invention of the JDT team, > but directly taken from the JLS: Yes, 'Finally' is part of the JSL but how the message is crafted together is an invention of the JDT team ;-) Maybe we could resolve the Finally as indicated in the JLS i.e. Syntax error, insert "Finally" to complete BlockStatements resolve "Finally" ==> Syntax error, insert 'finally' Block to complete BlockStatements > Changing anything here in a consistent way will be a major change. In that case I wouldn't touch it, except for removing the double quotes. We shouldn't spend a days on this.
(In reply to comment #7) > This is what javac 1.7 says: > > Snippet.java:5: error: 'try' without 'catch', 'finally' or resource > declarations I think it should be possible to augment the grammar with some error productions so that it doesn't trigger recovery due to parser error, but we accept the malformed construct and diagnose it precisely. That said, (In reply to comment #8) > Changing anything here in a consistent way will be a major change. I am afraid so.
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.
