This is a talk for CocoaConf Columbus talking about various breakpoints and why you should be using them

1. Bug Hunting Safari!
Janie Clayton-Hasz

2. Why is Debugging Hard?
• We all know we should debug, but many people
don’t know how to do it well.
• Our community does not have an overly broad
knowledge base about doing in-depth debugging
because it’s hard to make time to learn it better.
• We like to think that we can write all of our code
perfectly without any mistakes, but unfortunately
that is not the case, no matter how hard we try.

3. – Crow T. Robot from Mystery Science Theater 3000 for those under the age
of thirty or over the age of fifty
“Well, believe me, Mike, I calculated
the odds of this succeeding versus
the odds I was doing something
incredibly stupid… and I went
ahead anyway…”

4. Why is Learning Efficient
Debugging Important?
• Depending on the source, it is reported that a
professional programmer spends only 1/6 of their
time coding. Most sources agree that half of your
time as a programmer will be spent debugging
yours and other people’s code.
• Learning tools, tricks, and common problems will
free up more of your time so you can code rather
than debug!

5. Why is Learning Efficient
Debugging Important?
• At some point in your career, you will be working on
code that you did not write yourself. The previous
person will do things differently than you would
have and you need to be able to figure out why
something you did not write works and breaks.
• You will continue to grow and mature as a
developer. Looking at code you did three months
ago can be painful and you probably won’t
remember what you did or why.

6. Setting up Your
Debugging Environment

7. Why Have a Debugging
Environment??
• Everything you do in work and in life is better when
you have a dedicated set-up for it. Look at your
kitchen. You have a dedicated space to doing a
specific task and everything is arranged to make
that as easy as possible
• You have, or should have, a dedicated coding
space to help you focus and be productive. If you
want to be a productive debugger, you need to
care about setting up your space and your tools.

8. Debugging Console
• Create a dedicated debugging tab
• Make sure your bottom view is exposed
• Can set many things to optimize debugging in
XcodePreferencesBehaviors

9. NSLog(): First Line of
Defense!

10. NSLog()
• NSLog() is a function that you can use to print a
message to your console.
• NSLog() is a development tool. Nothing printed
using NSLog() is seen by the user
• Usually used to print out variables to the console in
order to check their value and to ensure they are set
• First type of debugging most people learn how to
do

11. Breakpoints!

12. Thing I accidentally make
when I click on an error
message that makes my
program stop running.

13. Flavors of Breakpoints
• Breakpoint Logging
• Exception Breakpoints
• Conditional Breakpoints
• Symbolic Breakpoints
• Watchpoints

14. Advantages of Breakpoints
• Easier to clear out of production code than NSLog()
statements. You should not include NSLog()
statements in an app that is submitted to the App
Store
• More flexible than adding code to your project for
debugging
• Less likely to generate errors because you are not
adding additional code to your project

15. Breakpoint Logging

16. Logging with Breakpoints
• Think back to when you were creating all those
NSLog() statements. They were kind of messy,
weren’t they?
• You can use breakpoints to do the same thing

17. Exception Breakpoint

18. When Do You Use an
Exception Breakpoint?
• Have you ever built and run your application only to
have it crash and direct you to the Main.m file? You
know the problem isn’t there because you haven’t
touched it. How do you find out where the problem
actually is?
• You use an Exception Breakpoint

19. Exception Breakpoint
• What happens with Xcode is that when it
encounters a problem in your code, it will keep
going until it crashes. That is why it usually stops in
the incredibly unhelpful Main.m class rather than
where the problem actually is.
• By creating an exception breakpoint, you are telling
Xcode you want it to stop where the problem is
rather than to keep going and crash somewhere
else.

20. Conditional Breakpoints

21. Conditional Breakpoint
• You are telling Xcode to stop if a condition is not
met.
• The condition must equate down to a true or a
false.
• You can use this in a loop if you need to know what
the result of a certain iteration is by setting “Ignore
’n’ times before stopping.”

22. Watchpoint

23. Who Watches the
Watchpoints?
• Watchpoints are a tool you can use to keep an eye
on any object that is going to undergo a change.
• For example, if you have a label that is updated by
input from the user, you can set a watchpoint on it.

24. Symbolic Breakpoint

25. Symbolic Breakpoints
• Used any time a specific method type is called.
• For example, if you want to know every time the
view loads you can create a symbolic breakpoint to
do something when viewDidLoad is called.

26. LLDB: Or How I
Stopped Worrying and
Learned to Love the
Command Line

27. What is LLDB?
• All of the tools we have been working with so far
are written in LLDB.
• LLDB uses a command line interface.
• Anything you did in Xcode, like setting a
breakpoint, can be done on the command line in
the debugging console.

28. Why Would I Want to Know
LLDB?
• LLDB has more functionality than what has been
built into the user interface in Xcode.
• Writing code in the command line is faster and
more efficient than having to use the mouse to
move around selecting user interface elements.
• You can do debugging in the terminal and bypass
Xcode completely. If you want to use something
like AppCode, this is a way to use LLDB.

29. Why Would I Want to Know
LLDB?
• You can customize LLDB commands to suit your
projects more closely
• You can extend LLDB’s functionality with the use of
Python Scripts

30. Creative Way to Torture
Your Coworkers

31. Sound Breakpoints!!
• You can program a breakpoint to generate a sound
when something happens.
• When you go on vacation, program all of your
breakpoints to make annoying sounds when the
program is running. Your less knowledgeable
coworkers will go crazy figuring out where the
sound is coming from!! BWHAHAHA!!!

32. In Conclusion…

33. 99 little bugs in the code!
99 little bugs!
You take one down,
You patch it around!
117 little bugs in the code!

34. Bugs are bad. You do not want bugs. You do
not want to ship an app that has bugs. Bugs
are the number one reason that apps are
rejected from the App Store.
!
Bugs happen. You don’t want to ignore little
bugs…

35. Because they become
BIG BUGS!!

36. `