I’ve recently started work at Rain as an Android developer and this is my first post on the Rain blog. I work with some extremely talented developers and so I recently decided to brush up on my debugging skills to make sure I can keep up with everyone. In my study I was able to refresh myself on some tools I had neglected and I also made several exciting discoveries of some debugging tools that I can’t believe I’ve been living without. My productivity has increased as I’ve implemented these tools in my daily work flow and I hope they help you as well. I’m a loyal Eclipse user but I know that similar features exist in other IDE’s such as IntelliJ, Xcode, and NetBeans.
Conditional Breakpoints
I’m sure many of you, like me, have encountered interesting and hard to fix bugs in your software. My first impulse is to view the stack trace, find the point of failure and set a breakpoint so that I can see what things look like when my code is failing. This works pretty well about half of the time. The other half of the time, that breakpoint gets put in some code that is called frequently by many other parts of my code which causes execution to stop much more frequently than I need. Then debugging becomes an exercise of looking at certain variable values and iterator counts. Conditional breakpoints allow you to have the debugger stop only when certain conditions are met. (Queue angelic choirs) Here is a snipped of very interesting code from an Android application that we will use as an example:
lets suppose we want to stop execution of our for loop on even integers. First, set a breakpoint inside the for loop. Next, right click the breakpoint and select “Breakpoint Properties”. Check the box for “Conditional Breakpoint” and set the condition as “i % 2 == 0” as pictured below. Once nice thing to note is that the condition window has full code completion for all you Cntrl+Space enthusiasts. After you have done this go ahead and run the debugger and see how it stops on all the even numbers. Pretty sweet.
Watchpoints
Watchpoints are similar to conditional breakpoints except that they just stop execution if a class variable has changed. to set one, just put a breakpoint to the left of a class variable, it automatically sets itself as a watchpoint. You can then configure the watchpoint’s properties to stop on either access or modification or both. Unfortunately the Dalvik VM doesn’t support watchpoints and so this doesn’t work for Android projects.
Suspending the VM
Eclipse also allows you to specify whether a breakpoint suspends only the thread that the code is executed on or the entire VM. This was an important discovery for me on the current project that I am on which has several background threads which my UI thread relies on. By default, breakpoints only suspend the thread that that code is executed on. When I would debug my application, the current thread would suspend but all my background processes would go on their merry way. This caused problems in identifying bugs that occurred based on some external conditions on other threads. If you look closely at the breakpoint properties window you will notice a radio button for suspending execution on just the active thread or the entire VM. Suspending the entire VM is useful in situations like mine so that I don’t miss any code execution that happens as a result of other threads.
Exception Breakpoint
Who doesn’t hate NullPointerExceptions? In Eclipse you can tell your debugger to stop execution every time you are about to get one, or any other exception for that matter, with an exception breakpoint. These are extremely useful and you can also set custom properties for them. Exception breakpoints can stop on caught and uncaught exceptions and even subclasses of exceptions. This is a powerful breakpoint because it allows you to be more proactive in your debugging rather than hunting down your exceptions when you get them.
Debugging Keyboard Shortcuts
This is a convenience tip. There are a few keyboard shortcuts available while in debug perspective.
- F5 – step in
- F6 – step over
- F7 – return
- F8 – play
I hope this article helps you in your debugging tasks. If you have any other useful tips please add them in your comments below. Thanks for reading.
Wow, great to know about stopping the entire VM, I really hated all this mess with working threads.