Debug mode - GirlsOfSteelRobotics/2015season GitHub Wiki

Debug mode lets you run your code as normal, but pause execution at certain points so you can check out what's going on/awry. You run debug mode the exact same way you run code normally, but from the debug menu. Its icon looks like a little bug, and it's right next to the button you hit to "Run as..." (but you select "Debug as..." instead). The little bug button looks like:

Breakpoints

To pause your code, you set "breakpoints." You set a break point by double-clicking in the far left column of the source code editing pane on the line where you want a break point. It's blue. You can also right click that region and select "toggle breakpoint."

A breakpoint looks like:

Pausing execution.

When Eclipse starts to execute the line of code at a break point, it pauses, and usually switches to debug view (if it doesn't, it's one of the perspectives you can open up in Eclipse). Look in the upper right; you want the debug view to be selected. Its icon looks like:

When execution is paused, you can look at all the variables that exist at that point and see what their values are. You can either hover over the variable in the code pane, or look at it in the variables display in the upper right. A bad example image of that pane is:

This helps you learn more about many things, including exceptions. You might also check variables in your own code and see if they are what you expect them to be at particular points.

Interacting with your program when it's paused.

There are a bunch of buttons in the upper left-ish region that you can use to interact with your program when it's paused. You can hit "play" to keep running from there (and the program do its normal thing, at least until it hits another breakpoint). The play looks like:

Terminate is right next to play. It looks like a stop button:

You can "step over", which means just execute this one line of code and stop at the next line to execute in this method (or the one that called it, if you're at the end). Its button looks like:

You can "step into", which means to enter the functions being called on a line:

You can "step return" which, if you're in a function you've stepped into, executes the function until it finishes and then stops again at the next line after the function has returned. I don't have a good picture for it right now, I'll work on that...

Example use of the debugger

For example, we had a problem on January 20 in that the robot was failing to initialize. The Dashboard displayed a really obscure error message. Reading more closely, the error message said (among other things) that an exception was being thrown at line 149 in one of the wpilib classes. We opened the wpilib jar, found that file, and put a break point at that line (which was trying to load the robot class). We then ran it in Debug mode, and stepped over the line after the execution paused on the break point. The code still threw the exception (so the next executed line was in the catch block), but now we could expand the exception variable (the Throwable t in the catch block) and look at the "detail" field. It showed us some additional notes that indicated that there was a problem with one of the Channels (in the first instance of the error we investigated, channel 29 didn't exist). This helped us diagnose the problem as being with the whole channel mapping scheme overall, which I'm sure you guys fixed once I went home to have dinner. ;-)