So what I want to do is set a breakpoint somewhere where something meaningful has happened, so what I want to do specifically is look at this swipeLeft event and stop execution when it happens. So what I'll do is set a breakpoint here on the line inside the callback function that's called when swipeLeft happens. Okay so, I've set the breakpoint and nothing really happens yet, I need to trigger it, so I'm going to open my color box and swipe left. As soon as I do that, I get the message that we are Paused in the debugger with couple of buttons up here.
We'll deal with those later, but for now I can see, here is the line that I'm trying to execute, it's highlighted nicely and I see a whole bunch of new stuff over here on the right side. I'm going to close the Call Stack for now, because all we're interested in for the moment is this Scope area. Now different debuggers will call this different things, but this is all the state of the currently known variables, and as it says, these are broken down by scope. So I have my Local scope and my Global scope. It's just these two for now, but as you'll see later, there are many occasions where you'll see quite a few scopes.
I have the event, the actual event that was fired, and then fingerCount, now this is not a touch interface, so there are no fingers involved, so that is set to zero, and then I have this, which is a jQuery collection. That's in the Local scope and then in the Global scope, I have a, oh boy, a lot of stuff. We don't need to care about most of that. We can see that the $ is our jQuery object and then all of these other variables that are sort of faded out a little bit are the ones that are inherited and known about, but not necessarily explicitly defined in the code that I've written.
Okay, so you can see, already this is pretty cool. You can see a lot of what you're actually interested in in the context of where you are. And it's just sitting here waiting for me to either do something or let it continue. So breakpoints can be set at any point. I could set another one down here now, I could set one pretty much anywhere in this code and then when I want to let the code resume executing, I could just hit this Resume script execution button here. And now, everything that was supposed to fire afterwards, unless it hits a breakpoint, will continue executing.
I set a second breakpoint here in the swipeRight method, but that breakpoint is not hit in the swipeLeft method, so we never stop again. But if I do swipe right, you can see that line is highlighted, and we pause again at the breakpoint. So, here's my right and my distance and duration and all that other stuff, very good. One interesting thing about breakpoints, I'm going to let this resume, is that they're preserved between reloads, so I reloaded the page and those same breakpoints are still there and they pause just like they did before.
Hit that Continue, close it again. These breakpoints only fire when I actually do something. I can take those out and then set another breakpoint here in the ready function. I set one here on this line. One note, you can set breakpoints pretty much anywhere in this debugger, not all debuggers will let you set a breakpoint on say, a non-executable line, like a comment. You may find that if you do this, depending on the debugger you're using, it could get moved to the next available executable line. I'll set one here on one that actually does something, that is the variable assignment.
Now if I reload the page, I don't have to do anything. This is something that executes on its own without my intervention. And now I can just see that I have my accidentalGlobal, which currently is not defined. Because I've stopped on this line, I haven't executed it yet. And then we have the bigErrorStyle which is also known to the debugger, but currently undefined. I'll let this go. One other note about breakpoints, if you set one in your code here, I said they were remembered between reloads, but what if I edit my code? So, I going to switch back to the text editor.
I'm going to scroll up and my breakpoint is currently set on line 309. So I'm going to add another comment above this and save the file and switch back. Now if I reload, my breakpoint has moved to stay with the line of interest. That's pretty cool. Depending on the sort of changes that you make, the browser may not be able to figure out exactly where to put the breakpoint that you previously set, so you might see different behaviors like it being removed or just moved to a line that you didn't expect, so you may need to clear them and reset them. One more thing about breakpoints, you don't have to set them in the browser.
If for some reason, you can also set breakpoints in your code, if you want to do that, you can just jump to the place you want a breakpoint to be and type "debugger;" on a single line like this. I'm going to save that and switch back to the browser. So here, no breakpoints, I'm going to reload, open the color box, and swipe left. There we go, it stops on that debugger; line. Now generally speaking, I find that I end up using breakpoints in my actual debugger in the line gutters like this.
But sometimes you'll end up using something like this. There might be times where you want to have the debugger start up immediately whenever your code loads without having to open its user interface and find the right lines and set the breakpoint. If you're spending a lot of time in your code, more than you're spending in the debugger itself, then this could be useful. They operate just like any other breakpoints. So, that is a look at the basic use of breakpoints in the debugger. They can stop the execution of your code and let you look around at all the variables that are currently defined.
- Getting the browsers and plugins
- Leveraging the Console API
- Using breakpoints
- Using step functions
- Watching variables
- Debugging jQuery, WordPress, mobile sites, and more