Swift Components Tour – Unique Breakpoints

In this lesson

Back in the Swift Components Tour app, let’s talk about my three favorite breakpoints that aren’t your momma’s everyday breakpoints.

Kyle Roberts
Swift Guru at Large

Kyle's Series


Tap on time to skip ahead


Hello world! Kyle here with Brax.tv and today we’re going to talk about some special breakpoints. I have three in mind that we’re going to talk about. These are three that I typically keep in this breakpoint bank over here. We are going to add them to this project since they do come in handy in the situations that you would use them in. We’re going to add them here and talk about how to use them and why I like them.


The first one we’re going to add is an exception breakpoint. We can go down here under the breakpoints navigator to this little plus button down here and we get a little action menu. We will choose add exception breakpoint. Right now, it is set for all exceptions and you can right click and edit it and work on some tweaks and stuff. It’s easiest for me, and I’ve always just kept it normal, vanilla, all exceptions breakpoint.


I’m actually going to add a crash into the app. The crash that I’m going to add is we’re just going to NSLog an element that does not exist in this waiting strings array. Since there are four elements we can actually print to the log, waiting strings object at index four. Since index four would actually be the fifth element in the array. It’s not there. So the app will crash. What’s cool about exception breakpoints is the app crashes due to an expectation-not because it ran out of memory, or a broken reference to something-for an exception crash, which is normally what logic crashes that you run into are.


I’m going to open this view controller and we put it into the method textFieldDidChange. Let’s just click on a text field and edit that. The app will get to this line, it will run this line, it will throw the exception and before the app crashes it will put this little red breakpoint indicator here with the crash in this description to the right to tell us what was happening. We can maybe see what was going on at that point in time in the scope of the crash to maybe find out what caused it. We can see anything that was printed to the log, this was now printed to the log because that’s what crashed.


We can look at some current values and just the general “what was going on” in this class and in this method that made it crash. We know that it’s none of this stuff, it was just this line that I put here. We can continue program execution over that and sometimes you’ll maybe get some more debug log output but just because this is a crash that we put there’s not much to it. It’s kind of obvious, we can just get rid of that. But the breakpoint did point right to this line where the app did throw an exception which is awesome and very useful. I just did some weird backspacing so I’m going to fix that up and stop the app.


Let’s talk about the next breakpoint. I’m going to keep this one here, and I’m going to keep it active just in case we would maybe run into an exception later. I don’t think we will but it’s nice to have.


This next breakpoint is called a symbolic breakpoint. Sometimes when an error or warning is thrown during a runtime of your app, they actually have these symbols that are available that a symbolic breakpoint can catch. You can see here that the example is on an NSExectpion, so we could add an exception breakpoint custom with the symbolic breakpoint input. Since the exception breakpoint is popular and useful by itself that it has it’s own little exception breakpoint menu or item in that action menu. So I’m going to get rid of this and we’re going to go a situation where I like to use the symbolic breakpoint and that is when dealing with auto layout.


I’m going to open up the gestures view controller where we have a lot of UI gesture recognizers that are going to be working with auto layout constraints to interact with this blue square in the center of this screen. Something that I haven’t gotten around to fixing with the Swift Components Tour app yet is that this screen has a lot of constraint conflicts. They’re not bad because they don’t actually make the app crash and it still behaves how you would expect it. We just get gobs and gobs of debug log output from that. We can see here at the bottom of the output it tells us that we can make a symbolic breakpoint at this symbol. I’m going to copy that with Command+C to catch this in the debugger.


What is cool and awesome about these symbol breakpoints is I’m going to create one, I’m going to copy that symbol into there and no worry about any of the other items in there. Just run the app again so that when we do open this screen and we perform one of the gestures it’s going to throw that constraint conflict warning back into the debug log again. I’m just going to move this and before it actually moves we’ve hit a breakpoint. This does not look very useful but that’s because we are actually in this file or realm, whatever’s going on right here in this UI alert or unsatisfiable constraint something. It looks like a lot of pointless nothing. Maybe what you would do if you were a hacker in a movie, you could read this.


But we do see something familiar here and that is a file we created in NIOGesturesViewController. I’m going to click on that, that is in in a different place in that main thread. We can see that this breakpoint has stopped at the line that is causing trouble. That is maybe causing this constraint conflict. If I do take the time in the future to fix this, then I know that I can find it right here instead of wondering “hey, I’m on this screen and look at all this auto layout constraint stuff I’m doing. I have to go through each one and make sure they’re perfect and figure it out in my head.” No, we have this symbolic breakpoint on that unsatisfiable constraint symbol so we know the issue is right here.


We can continue program execution and we have hit another. Let’s go to the view controller. We can see that it’s hit a different part of the method. Before we were on this left constraint one and now we’re on this top constraint one. They both are doing sort of a similar thing so maybe this logic is causing an issue when we’re adding a pointInView .x or .y. Let’s see how many there are. I’ll continue program execution and that looks like the only issue. We can see that they’ve both printed their output to the log and they’re telling us that we can create that symbolic breakpoint here. But that’s for another time.


We’re going to look at the final breakpoint, which is a test failure breakpoint. We have not talked about any unit test stuff yet. You’ll just have to bear with me. This is useful when you are running unit tests. We can see that there is a tab in the test navigator, a tab in this navigation stuff up here call the test navigator. Here we see that both of our tests should-we have two tests in this auto created file called Swift Components Tour test. Both of these test are just templates stuff. Let’s actually change one of them to fail.


Then we can run the unit test up here by hold and click by this run debug stuff until the action menu pops up and select test. We’re going to build the test and run the test. We should see, since we have our test failure breakpoint, that we’re going to hit it on this test that would fail. We know which test failed and where it failed, why it failed, we can see what’s going on in the current test class right here.


If we continue program execution over that, it will go over this and we will get a lot of visual cues that we had a test fail here. We see that this test class was marked as test failure. This method was marked as test failure, and this specific assert was marked as test failure. So since this assert failed it says the method failed and it says the whole class failed. We can see that in the test navigator up here. It was useful because we had this test failure breakpoint anyway. When you have some longer tests or bigger tests this can still be useful even though you have all these other visual indicators.


These are my three favorite breakpoints. I’m not counting just standard breakpoints that you would throw in anyway. These are my favorite special, unique, custom breakpoints.


Typically how I use these is I keep the exception breakpoint on all the time. I deactivate the UI alert for unsatisfiable constraint symbolic breakpoint and I deactivate the test failure breakpoint. Yes, there are cases where you would want to deactivate the exception breakpoint. Some libraries and frameworks sometimes do throw exceptions that don’t crash the app. Some apps I’ve worked on every time you launch the app you’re going to hit a couple exception breakpoints and it’s just annoying and easier to turn that off.


You can get even more custom with this and say don’t throw any exception breakpoints until after these other breakpoints have been run so we can avoid any of those exceptions that might be coming from third party systems.


The reason I keep this symbolic breakpoint off for unsatisfiable constraints is that during development, you’re more worried about getting the feature done or fixing a bug then, maybe if there’s one constraint that’s off. It is useful to turn this on. Sometimes if you have a screen that is a little buggy or a little laggy. Fixing some of these constraint issues can clean that up and make it a little speedier and more responsive. Keeping the test failure breakpoint inactive, it’s really up to you and it only really matters when you’re working in the unit test or running the unit test target or files. But as you’re writing new unit tests you’re not going to expect them all to pass the first time. Once you get a good basis of unit test going, maybe after you have 50, 100, 3 or 400 unit tests, you can keep this on so that you do know when any of them fail. You can just fix while you’re running through the execution of the unit test target.


If we do run this we are going to hit this first breakpoint, we can change that to true so that it does pass, or fix whatever’s going wrong in this specific test that hit the test failure breakpoint and skip ahead and just continue for any of the failing tests for that. When you rerun the test target they should all pass as long as you’ve fixed them all. Which is great. I would really recommend all three of these breakpoints. There are more useful ones and there’s even an item down here that we didn’t even cover that has to do with open GL, which is nothing even close to what we’re doing in Swift Components Tour. So there you have it. Special breakpoints, unique breakpoints. Thanks for watching.

Additional Info

Register to get access to additional resources and info.