Leave a rating/review
In this episode, we’re going to take a look at our first bug. My testers are telling me that there are all kinds of bugs; just like in my house!
Tapping the plus ‘+’ button doesn’t work. Text is missing from my task cells. There is a weird triangle showing on the left side of each task row. And we seem to only have tasks with a priority of “none” when our app supports more priorities.
Honestly, there are a lot of bugs, and I’m not too sure what may be causing them or where to begin looking. Fortunately, breakpoints are just the right tool for this situation.
Before looking at our bugs, the first thing you want to have at your disposal are line numbers.
Open the starter project for this episode in Xcode.
Now, go ahead and open ContentView.swift. Notice how the editor has a number to the left of each line. If you are asking yourself: “How is that going to help me debug things?”, the answer is that it alone will not do the job. What line numbers do help with is communicating with fellow developers about what exact line, or lines of code, you are referring to.
Line numbers are also helpful when certain exceptions or crashes occur. In those scenarios, Xcode, or your crash logs, may contain the exact file and line number that caused the crash, thus leading us back to having line numbers visible in the Xcode editor.
If your editor doesn’t look like this, then go to the Xcode menu item and click on Preferences…. Click the Text Editing tab, and make sure the Display section is selected.
In here, make sure the Line numbers checkbox is selected. Finally, close the Preferences window to go back to the main Xcode window.
Time to find bugs!
Let’s do a live preview in order to see some of these bugs.
Woah! Just as our testers said. At a quick glance, we seem to be missing the text for each task, instead of showing a checkmark for completed tasks we are showing a triangle, and we seem to be default to showing completed tasks as soon as we launch the app. Not ideal!
When you get a bug report it’s really helpful to try to see it yourself, especially if it’s a bug that only happens in certain situations. Understanding the conditions necessary to reproduce a bug can be really helpful in finding the cause, and, thus, in finding a fix.
Sometimes you can just read the code and see what needs to be fixed. But here, looking at the code and our different views, it’s not immediately obvious what is wrong.
You’re going to have to dig a little deeper.
You can see the code you’ve written and you can see what’s showing up on the screen, but somewhere in between there, something went wrong. It would be nice if you could pause at different points in the application to see what’s happening; that’s what Breakpoints are for.
There are several ways to create a breakpoint, but the easiest is to click on the number for the line of code where you want to pause. You want to pause where the icon for a completed task is added to a row.
Open RowView.swift and click on line 42. You’ll see this indicator showing you that a breakpoint has been created on that line. Run the application, this the using a simulator.
Now, you’ll see this line highlighting the line of code where you set the breakpoint. That’s Xcode telling you that it has paused execution of your app at that line of code.
We say a breakpoint is hit when the line of code where the breakpoint is set is about to be executed and Xcode pauses there. In later videos, you’ll learn how to do more with the code when it’s paused, but for now, you just need to learn how to continue your paused app.
Down here at the bottom of the editor window is the Continue button. Click it in order for execution to resume.
The breakpoint indicator is a nice way to visualize where breakpoints are set in your current file, but to manage all of the breakpoints in your project you’ll want to use the Breakpoint navigator.
On the left, in the navigators pane, the breakpoint symbol denotes the breakpoint navigator. Click this navigator and you’ll see a list of all the breakpoints in your project and where they’re located.
Awesome! We’re learning about breakpoints, and starting to leverage them in order to reproduce and subsequently fix our bugs.
In the next episode, you’ll continue to learn how to work with breakpoints; including how to enable, disable, and delete them.