 Welcome to debugging. What is it? In this learning activity, you'll get an overview of debugging, including what it is, why you use it, and what debugging looks like in action. Imagine you're the lead guitar player of a very cool and popular rock band. You're about to play the biggest gig of your life at the O2 Arena in front of 20,000 screaming fans. The crowd goes wild as you take the stage. You stare out into the blaring lights, barely able to make out the waving hands. But you can hear the roar of the crowd. You pick up your guitar and prepare to rock the house. One, two, three, four. You strike the opening power chord and... Nothing happens. No sound. How would you figure out what the problem is? After rapidly leaving the stage and yelling for your guitar tech, you try and debug your rig. Debugging is the art of diagnosing and rectifying errors, or fixing bugs. In programming, it's designed to find problems in your code. There are many, many different types of programming bugs. Math bugs like calculating sales tax using the wrong percentage, logic error bugs like failing to exit a loop at a certain condition, and system bugs which include failing to handle a full disk, as well as syntax problems like incorrectly formatted expressions. It may seem like there's no end to the types of bugs creeping into your code. While using good techniques minimizes bugs, they're still bound to happen. Using debugging tools and practices allows you to find and fix them. To debug your guitar and go back on stage, you have to first understand your system. In your rock band, you have to know what connects to what. Your guitar connects with a cable to an effects pedal, which connects via another cable to your amp. First, you make sure your volume knobs are turned up. Then, you test your pedal to make sure it's on and working. You check the amp. Is it on? Yes. Is it in standby mode? No. It should be okay. You test to see if the problem is between the guitar and the amp by connecting a new cable directly from your guitar to the amp. Sound! Aha! Well, what does this tell you? You've learned the problem is somewhere between the cable and the effects pedal. By swapping out every cable, you find the one that's bad, replace it, and you're ready to go back on stage. You've just debugged your guitar system. Diagnosing software problems is no different. Because you start with a symptom, you find the cause and fix the fault. Unlike fixing a guitar system where you have to physically replace parts and test connections, when fixing software, you can instantly move to any part of the code and test the logic to see if it's working as expected. Let's look at a typical software bug to see how you can find it and diagnose it. Check out the following code. It's getting some website data and displaying it in a message box. This code is in a button click event handler. That is, clicking a certain button executes this code. The first line of code creates a web client object, which allows you to download website data. The second line downloads the sample.txt file at plop.com and returns its contents into the string named data. The third line shows that string in a message box. If you run this code and you're connected to the internet, it pops up a message box with the words, hi there, like so. But what happens if your internet connection is down? Then you'll get this message. Uh oh, what do you do now? This is a hard bug to track down with tools because the code only fails under a certain condition. The user doesn't always know when the internet is down. They only know they saw this strange message right before the application crashed. The first question to ask yourself is, well, what do I know? You know the app crashed when the user pressed this particular button, so you start looking at the code behind the button. Any seasoned developer would shudder at this code. Why? Because it's calling out to a resource outside of your control and there is no exception handling code in place. Here's a rewrite using a try catch block. The try keyword sets up the block of code directly below it for exception handling. If any one of those three lines of code causes an exception, the code in the catch block executes and it has access to the exception data via the EX variable. In this case, all you're doing is showing the message attached to the exception, which gives you a high level view of the problem. Once you've fixed the code, you'll get this message box when it runs and the internet is down. The remote name could not be resolved, prop.com. Now at least you know there's a network problem somewhere. Using Occam's razor, which states the simplest explanation is usually correct, there's probably an internet connection problem instead of a configuration problem. You pull the plug on your development machine, which disconnects it from the internet, run the app and boom, you've reproduced the bug. How to fix this bug is another story for another day. Just as you had to walk through the steps of your rig to fix your guitar's sudden silence, you can also walk through coding steps to find out what's throwing an error. This is called debugging. In this learning activity, we learned what debugging is, why you need to do it, and what it looks like in action. You've completed debugging. What is it?