Community
Participate
Working Groups
Currently if you try to perform an evaluation (conditional breakpoint, Inspect, Disply, etc) and it fails you will get an error dialog that sometimes will hint at what is wrong, but most often will be the completely useless / cryptic "Evaluations must contain either an expression or a block of well-formed statements". We should change this to provide a multi-status to the dialog that describes the errors found in the snippet - which is easy to do because our evaluation engine collects the instructions with errors and does nothing with them except to know that an error was found.
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.
