I am running Android Studio and setting breakpoints, but on both of my IF...ELSE conditions, the code is not being executed. It seems to me that such a thing is impossible. Either the IF or the ELSE should be true... right?
The code is this:
if (lastReading.isItTimeYet(Calendar.getInstance()))
{
lastReadingReturn = lastReading.SensorReadingChanges(z_value, chkOrient, inclination, rotation);
if (lastReadingReturn.isEmpty())
{
String EMPTY = "TRUE";
// DO NOTHING
}
else
{
int stopHERE = 0;
}
}
lastReadingReturn is a string. It is getting a value from SensorReadingChanges just fine. I don't see any errors being thrown.
I put break points on both the String EMPTY = "TRUE"; line and the int stopHERE = 0; line, but neither is hit. I can stop on the line before the if. But when I try to step into or step over the next line, the debugger jumps to the first line of code that is OUT of the If clause. In other words, it just skips it.
I have run it with both conditions (i.e. the string being checked is empty and the string being checked has a value) but it doesn't matter. Neither is hit.
Here is a screenshot of my Android Studio running in debugger:
Both your if-block and your else-block contains code that is very likely to be removed by the compiler during optimization since they actually don't do anything.
Try replacing them with something that actually does something like logging a message or move the declaration of EMPTY and stopHERE outside of their respective blocks.
String EMPTY;
int stopHERE;
if (lastReading.isItTimeYet(Calendar.getInstance()))
{
lastReadingReturn = lastReading.SensorReadingChanges(z_value, chkOrient, inclination, rotation);
if (lastReadingReturn.isEmpty())
{
EMPTY = "TRUE";
// DO NOTHING
System.out.println("Doing nothing");
}
else
{
stopHERE = 0;
System.out.println("stopHERE set to zero");
}
}
Edit: Since I'm not being believed I simulated OPs issue in Android Studio:
final Random random = new Random();
if(random.nextInt(1) != 0) {
String EMPTY = "EMPTY";
} else {
int stopHERE = 0;
}
So, Android Studio is actually warning us that there is no executable code inside our else-block where the breakpoint is.
When run, this will only pause execution once, on row 18 (since random.nextInt(1) will always be 0).
Related
I am getting ~20'000 rows out of a database with JDBC in Java, Eclipse IDE.
I go through the result set step by step (ordered by id). Every row contains information about its previous and succeeding "identifier" (unique string of a row). So for every row I check if the chain is broken or not, b/c of whatever reason.
My approach beneath works, and don't quote me on that, but it seems it works better for the first 10'000 than for the following. Error quota is 335 for 19'999 entries. I checked with my own eyes if the reported errors are in accordance with reality, but they are definitely not, at least for 1 error.
Do I miss something important? Why does this happen? It almost looks like it is the result of parallelization, multithreading, etc.?
int i = 0;
String actualprevious = "", previous = "", next = "";
boolean first = true; // we can't check if the first is in line because it is the first
int errors = 0;
while (rs.next())
{
if (i%10000==0) { System.out.println("Checked "+(i/10000)+" myriads."); } // inform
String current = rs.getString("identifier");
if (!current.equals(next)) { System.out.println("Current is: "+current); System.out.println("Expected "+next+" to be next, but "+current+" is."); errors++; } // inform
// ignore: Document doc = Jsoup.parse(rs.getString("source"));
next = rs.getString("next");
if (next==null) { System.out.println("There is no next listed in row "+current+"."); errors++; } // inform
previous = rs.getString("previous");
if (!first && !actualprevious.equals(previous)) { System.out.println("Expected "+actualprevious+" to be listed as previous, but "+previous+" was in document "+current+"."); errors++; } // inform
actualprevious = current;
i++;
first = false;
}
I am using debug mode in Eclipse Oxygen to, as you might guess, debug my code.
I am writing a backtracking algorithm (a recursive function - it calls itself).
In the Backtrack function there is a for loop, and at the end of the for loop, if certain conditions are met, this code is run: Backtrack(csp, index + 1, CopyCSP(currentSolution));.
I'm debugging my code, and I want to go to the next iteration of the for loop, so when I get to this line, I hit "step over." But it steps into, and walks me through the next Backtrack function.
I know for a fact that it is actually the next function, because as you can see, the index variable goes up by one, which happened.
Why is this happening? How can I avoid this and actually step over? If step over doesn't do what I want here, what should I use?
Here's my code for the full function:
private void Backtrack(CSP csp, int index, CSP currentSolution) {
//BREAKPOINT IS HERE
if(index == csp.numVars) {
currentSolution.PrintSolution();
csp.PrintSolution(currentSolution);
solved = true;
return;
}
for(int test = 0; test < csp.MaxDomainSize(); test++) {
if(solved) {
return;
}
if(test < currentSolution.vars[index].domain.size) {
currentSolution.vars[index].value = currentSolution.vars[index].domain.get(test);
}
else {
continue;
}
boolean satisfied = true;
for(int i = 0; i < csp.constraints.size; i++) {
if(!csp.constraints.get(i).Satisfied(currentSolution.vars, index)) {
satisfied = false;
}
}
if(satisfied) {
System.out.println("Variable " + index + " satisfied by " + currentSolution.vars[index].value + ".");
Backtrack(csp, index + 1, CopyCSP(currentSolution));
}
}
}
I've put a comment where the breakpoint is.
I was having a similar problem and found similar solution, posting here for reference.
Problem:
Debug session 'Stepped Into' each line for every 'Step Over (F6)' operation
Solution:
'Run->Remove All Breakpoints'
'Run->Restart'
Result:
'Step Over (F6)' steps over active debug line now as expected.
Sharing for clarity and simplicity if encountered, hopefully this helps.
Following the train of thought that it's the breakpoint...
A breakpoint stops the flow of control in most situations.
Eclipse has options to disable individual breakpoints and disable all breakpoints. Your situation might be right for conditional breakpoints:
Right click on the breakpoint and select breakpoint properties. This will bring up a dialog with "hit count" and "conditional" which works most of the time and is confusing when it doesn't.
If you check "conditional", this will enable a text box where you can write a condition to use the variables to make a true statement. So you could enter "index==1000" and then it would stop when you are 1000 calls deep.
I have not used "hit count" myself.
Disclaimer: I'm really new at this and I apologize in advance if:
1) my question has already been asked (I've tried searching and had a lot of trouble finding what I needed)
or 2) if I'm not asking the question correctly.
Basically, I'm trying to make a game where pressing the spacebar triggers a sort of "super-power" that will perform a set of actions just once. Afterwards, if they try to press it again, it'll run up some sort of dialogue box that says their one-time super-power has already been used.
What I have:
try {
Key move = canvas.getLastKey();
int space = 0;
if(move == Key.SPACE) {
if (space == 0) {
space = 1;
}
if (space == 2){
JOptionPane.showMessageDialog(null, "superpower already used");
}
}
if( space == 1 ) {
//action here
canvas.resetKey();
space = 2;
}
}
Right now, the super-hero action is on an endless loop but if I reset the key here:
if(move == Key.SPACE) {
if (space == 0) {
space = 1;
canvas.resetKey();
}
the user can just use the super-power over and over again. Any help would be appreciated!
In the third line, you have written int space=0 so your variable is constantly reset to 0...
You have to initialize it elsewhere (the beginning of your program is a good place for any global variable).
You should consider moving int space = 0, outside of the try block. I suppose your try block gets invoked repeatedly, so you should declare this variable under a global scope.
I'm trying to make a very basic game where you guess a number between 1-1000 using a do loop. Everything works, except when I finally make the correct guess, I am still prompted to make another guess, and when I enter the same correct guess again, the program terminates like it's suppose to.
Why do I have to make that extra guess to finally get my program to work? Am I looping around an extra time? Also, if I make a correct guess (the compiler will say I am correct then still prompt me), then a wrong guess (the compiler will tell me I'm wrong), then the correct guess again, the program will only terminate after I make the correct guess a second time.
The second do loop at the bottom is what I put in my main method. Everything above is in a method I wrote called play.
public static boolean play()
{
boolean c;
int n = 0;
do {
String input = JOptionPane.showInputDialog("Enter a number between 1-1000");
n = Integer.parseInt(input);
if (n == guess)
{
System.out.println("Correct");
c = true;
}
else if (n < guess)
{
System.out.println("Not Right");
c = false;
}
else
{
System.out.println("Not Right");
c = false;
}
guess++;
} while (c == false);
return c;
}
In main method:
do {
game1.play();
} while (game1.play() != true);
This loop runs the play method twice in each iteration of the loop :
do {
game1.play(); // first call
} while (game1.play()!=true); // second call
You are not testing the value returned by the first call, so even if it returns true, you would still call game1.play() again, which will display "Enter a number between 1-1000" again.
Replace it with:
boolean done = false;
do {
done = game1.play();
} while (!done);
This would only call play() one time in each iteration of the loop.
That said, I'm not sure why you need the outer loop.
You can just replace in with one call to game1.play(), since game1.play() will loop until the correct number is entered.
I've run into a really weird situation. I'm doing the following in Java (through Eclipse Galileo) on the Android 2.1 platform:
// Get gravity & geomagnetic data to return to the caller.
final int SIZE_GRAVITY = 3, SIZE_GEOMAGNETIC = 3;
final float[] NOT_USED = null;
float[] outGravity = new float[SIZE_GRAVITY];
float[] outGeomagnetic = new float[SIZE_GEOMAGNETIC];
final String NO_DATA_COULD_BE_READ = null;
boolean succeeded = SensorManager.getRotationMatrix(NOT_USED, NOT_USED, outGravity, outGeomagnetic);
if (!succeeded)
{
return NO_DATA_COULD_BE_READ;
}
Log.v("Test", "This should be printed - but it isn't!!");
// Prepare the data to return.
final int X = 0, Y = 1, Z = 2;
final String FIELD_SEPARATOR = ",", VECTOR_SEPARATOR = ";";
String returnValue = "" +
outGravity[X] + FIELD_SEPARATOR +
outGravity[Y] + FIELD_SEPARATOR +
outGravity[Z] + VECTOR_SEPARATOR +
outGeomagnetic[X] + FIELD_SEPARATOR +
outGeomagnetic[Y] + FIELD_SEPARATOR +
outGeomagnetic[Z];
// Return data.
return returnValue;
When SensorManager.getRotationMatrix(...) returns false, the Eclipse debugger shows that the if-statement that says if (!succeeded) suddenly jumps to return returnValue;. No exception is thrown and LogCat - even on verbose mode - receives no unusual message. It doesn't even receive the message I put in the code. I tried the obvious clean-and-restart-Eclipse approach and that didn't help. I'm very confused.
The Eclipse debugger is telling me that the second return statement is being called. However, putting additional print statements in shows that the first return statement is actually the one being reached. Perhaps I've stumbled across an Eclipse bug? Or anyone could explain this anomaly?
Looks like succeeded is false. Debugging will make it look like the method jumps to the bottom return when you do any return. Put a log before
return NO_DATA_COULD_BE_READ;
How are you sure that it jumps to the last return? You have a return in the if, this is most likely this one which is called.
I guess, you are in misconception. The control is not reaching the last return statement because the earlier return statement is getting executed.
return NO_DATA_COULD_BE_READ;
Since succeeded is turning out to be false (as you said), the if-condition is satisfied and then it simply returns the null value of the NO_DATA_COULD_BE_READ string, which is inside the if-condition block.
So, Log.v("Test", "This should be printed - but it isn't!!"); is never reached as per observation.