After 12 years of programming, I finally learned how breakpoints work. I tweeted about it and, surprisingly, a number of people asked for a tutorial—sure thing! I must say, though, that I haven’t double-checked that the way I’m using breakpoints is entirely correct, so hit me over the head if this post is a farce.

First, let’s start with the example code. Above is a simple test that draws a handful of randomly-colored stripes, as seen below. Click on the image to see a close-up of the code.

Now, what I want to do is see what the hex value is for the fourth stripe from the top. Prior to yesterday, I would’ve simply thrown a trace method in the loop and looked at the console. It works, but what if I want more information—I’d have to change the trace and recompile. Also, what if I want to prevent the code from proceeding past the loop—in case there’s a runtime error that I don’t want to deal with right now.

What I do is set a breakpoint after the loop. I do this by right-clicking the line number after the __build (); call. If I set the breakpoint on the same line number as the function, it will break before calling it.

This is what a breakpoint looks like.

This is what a breakpoint looks like on drugs, or after I run the debugger. At this point, it will stop and highlight the line you set the breakpoint on.

Head on over to the Variables view and it will appear as above. Expand the this item and it will show an [inherited] item. Expand that and you get a HUGE list of variables—some of which you’ve never imagined existed.

Scroll down to the array of objects (_objects) that held the colors along with the n value of each. Typically, you could just trace an array and it will display just fine in the console. That works only when the array consists of printable variables, such as numbers, strings, booleans, or classes that have a handy toString (); method. Unfortunately, this example uses Objects in the array, and if I traced the array, it would only show [object Object], [object Object], [object Object], etc. Luckily, I set a breakpoint.

Now, expand that _objects item in the Variables view and it will display the items in the array, annotated by the n value of the object—so we actually didn’t need to set one in the first place.

I pick out the fourth color down the list, expand it, and I have my values. It tells me the hex value as an integer along with the n value of the stripe.

Lastly, if you want to continue on with the debugging, click the Resume button in the Debug view.
This is an extremely simple example of how breakpoints can be used. In a real world scenario, I can set up multiple breakpoints, disable ones I’m not using, and enable them when I want to use them. I’m sure there’s a whole lot more you can do, but this example is based off how I use them without looking at documentation.
I haven’t written a tutorial post in a long while, but this has inspired me to continue with more. I’ll be sure to document my profiling workflow soon, which is essential for any developers concerned with memory usage and hanging references.