Summary: | Provide error details when any evaluation fails | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Michael Rennie <Michael_Rennie> |
Component: | Debug | Assignee: | JDT-Debug-Inbox <jdt-debug-inbox> |
Status: | ASSIGNED --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | curtis.windatt.public, daniel_megert, stephan.herrmann |
Version: | 3.7 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
See Also: |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=543604 https://git.eclipse.org/r/142538 https://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=2b10fc6998761578036ef32ce8ffcd41be72718e |
||
Whiteboard: |
Description
Michael Rennie
2011-06-15 12:51:31 EDT
I have seen this cryptic Evaluations must contain either an expression or a block of well-formed statements plenty of times, recently. Hence I suggest to implement Michael's proposal within the 4.12 time frame, given that it "is easy to do" :) (In reply to Stephan Herrmann from comment #1) > I have seen this cryptic > > Evaluations must contain either an expression or a block of well-formed > statements > > plenty of times, recently. > > Hence I suggest to implement Michael's proposal within the 4.12 time frame, > given that it "is easy to do" :) Unfortunately it is done at various places differently, so not very easy to do as I thought. Can you add may be 2 examples so that verify the changes I have in my mind. (In reply to Sarika Sinha from comment #2) > (In reply to Stephan Herrmann from comment #1) > > I have seen this cryptic > > > > Evaluations must contain either an expression or a block of well-formed > > statements > > > > plenty of times, recently. > > > > Hence I suggest to implement Michael's proposal within the 4.12 time frame, > > given that it "is easy to do" :) > > Unfortunately it is done at various places differently, so not very easy to > do as I thought. > Can you add may be 2 examples so that verify the changes I have in my mind. Sorry, I don't have any records of those situations. IMHO, even if not complete, just surfacing those errors in the most common situations would already be a huge help. I'd vote for Debug Shell as the highest priority. The exact kind of error that triggers this I can't tell you. That's what I hope we'll find out by better error reporting :) This comment was added as part of Bug 3103 (Commit fe0f813c0e21e68fb1a69966c92da75cb7f5e979) , where the error is a runtime error. Moving to 4.13 for a better understanding of problem. (In reply to Sarika Sinha from comment #4) > This comment was added as part of Bug 3103 (Commit > fe0f813c0e21e68fb1a69966c92da75cb7f5e979) , where the error is a runtime > error. > Moving to 4.13 for a better understanding of problem. In createExpressionFromAST() (modified in said commit) you directly operate on a "Message" which has getMessage() : String. Right in this section we see that the message is filtered for "void methods cannot return a result" -- aha! In all other cases you should have an interesting message.getMessage() at hand. That I want to see :) Btw, that code section doesn't speak of *runtime* error, it just tries to isolate runMethodError vs. snippetError, which I read as: if we have a compile error, is it inside the run method or elsewhere in the snippet? OK, looking at today's version of the code I see that errorSequence.addError(problem.getMessage()); is called in one branch, just not in the other. So the problems with insufficient error output result from IProblems with a range outside the original snippet. I quickly tried to trigger this situation with various forms of bogus code, but failed. New Gerrit change created: https://git.eclipse.org/r/142538 (In reply to Eclipse Genie from comment #7) > New Gerrit change created: https://git.eclipse.org/r/142538 @Sarika, while we don't have a recipe to systematically analyse, would you mind just a log warning in the otherwise silent branch? Maybe we can still sneak this in for RC1 to help us gathering information from the field? (In reply to Stephan Herrmann from comment #8) > (In reply to Eclipse Genie from comment #7) > > New Gerrit change created: https://git.eclipse.org/r/142538 > > @Sarika, while we don't have a recipe to systematically analyse, would you > mind just a log warning in the otherwise silent branch? > > Maybe we can still sneak this in for RC1 to help us gathering information > from the field? Yes, we can push this today itself, need not wait for RC1. Gerrit change https://git.eclipse.org/r/142538 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=2b10fc6998761578036ef32ce8ffcd41be72718e (In reply to Sarika Sinha from comment #9) > (In reply to Stephan Herrmann from comment #8) > > (In reply to Eclipse Genie from comment #7) > > > New Gerrit change created: https://git.eclipse.org/r/142538 > > > > @Sarika, while we don't have a recipe to systematically analyse, would you > > mind just a log warning in the otherwise silent branch? > > > > Maybe we can still sneak this in for RC1 to help us gathering information > > from the field? > > Yes, we can push this today itself, need not wait for RC1. Thanks! If someone observed any logs related to this, it will help to proceed. I don't know what else to be done here. |