Friday, March 29, 2024

.NET Debugging for Rookies

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Dubugging is either the best or worst part of being a developer, depending on your style. Myself, I can deal with the tiny bugs, but when the doozies come around I am easily frustrated.

This has been especially hard lately because I’m a lone developer now on my current project, and I don’t have colleagues to come take a look when I’m so frustrated that I just have to step away. So, I’ve assembled quite a system to ensure that the root of the problem is found and fixed and my app is back to being a well oiled machine ASAP.

I probably would have enjoyed a how-to like this before I got started, so I thought I would share it. This is aimed toward the greener folks, but you experts may get a few ideas as well. Many of these principals apply to all languages, so even if you’re not a .NET developer, read on.

Step One: The Basics. The worst phrase to a .Net developer? Object reference not set to an instance of an object. However that’s right where you start, sometimes the stack trace output can be a little overwhelming, but think of it as your first clue.

Look for the names of controls or classes. Usually it will at least tell you approximately where to start looking for your problem. Also ask yourself some questions: What have you changed since before this problem started? What’s the last thing you were working on? Think about your syntax. Anything you could be missing?

Step Two: Visual Studio Tools. Ok, here’s where you find out if it’s going to be an easy one or not.

Place a breakpoint somewhere before where your error originates (what the stack trace tells you or where you made your most recent changes). Then step through and step into your code in order to find the line that’s causing your app to throw the exception.

After you find it you can mouse over each of the components and drill down into its properties within VS. You can also use the immediate window to check values of different objects at runtime, or add a watch on one of them to see where and how they change. Use the great logic that made you a programmer to keep narrowing down what could be causing it. But if you still can’t find it proceed to step three.

Step Three: Other Very Useful Tools. Now it’s time to dig a little deeper, if you can’t find the issue behind your code it’s time to move to your other layers.

SQL Profiler, which is included with the MS SQL suite, is a great way to see what is being passed back to your database if you are using MS SQL Server. If you are using My SQL there is MySQL Query Profiler, and for Oracle there is EXPLAIN PLAN and tkprof.

Sometimes the error can be caused by a badly formed query or incorrect data, and that’s the way to find out. To inspect your HTML as it goes to the browser there is a great and free tool called Fiddler. Fiddler will break down all your http traffic on your local machine. You can set breakpoints and make real time changes. I have found it extremely useful in checking out my site (and others).

Firebug is a great CSS/HTML/JavaScript troubleshooter and debugger. It’s a free add on for FireFox (the developer’s browser) and though Visual Studio now has JavaScript debugging I still find it to be the most reliable.

Still stuck? Okay, on to step four.

Step Four: Reach Out. There are so many resources right at your fingertips – the Internet is a wealth of information.

My go-to guide lately is StackOverflow.com, the new undertaking by Jeff Atwood and Joel Spolsky. I won’t go into all the logistics, but you really need to check it out. It makes having and answering programming questions loads of fun using a Reddit type rating system, combined with a Wiki-like interface.

Right now I have 1,375 points, and today I got a question answered in 4 seconds. Unreal!

Other great places to go are Asp.Net, Microsoft’s Channel 9, and Joel Spolky’s .NET forum. Post your question and include as much information as possible, like bits of your source, your stack trace, and what steps you’ve already taken. This helps those that are taking the time to look at your problem by eliminating redundant work.

Make sure to answer any of their questions quickly, and to give them credit for the answer on sites that allow you to. Also, be sure to let them know they have led you to your goal.

Haven’t made any progress? Well, let’s keep going….

Step Five: The Scientific Method.A programmer I look up to a lot gave me this advice when he saw me get exasperated once.

Take out a piece of paper, write a yes or no question that you are asking yourself that is related to your investigation. Such as “Are all the properties of my business object being populated?” or “Is the method firing more than once?” Then go down that path and ONLY that path until you find the answer. If you run into new questions along the way write them down, but don’t deviate from your original goal.

After you find your yes or no answer move on to the next question. If there is no next question, come up with any possibility you can think of, no matter how outrageous. You will usually come up with more questions on the way.

The reason this can be useful is as programmers we can start to go all over the place when we are trying to track down the problem. We will go down one path, then come up with another possibility and try to see if that is the case, only to get lost on another track two minutes later.

But this technique helps us to focus on one issue at a time until every possibility is exhausted. I have found this to be a miracle cure for what ails me once I get to this point. I can’t tell you how many times this has saved me from tossing my laptop out the window.

Still having trouble? Wait! Hold on to that laptop – there is one more step.

Step Six Walk Away. Seriously get up and walk away. Go for a walk, play some Rock Band, call your hubby/wife, chat up a co-worker, anything that will make you completely stop thinking about your issue. Take a mini vacation.

Lot of times we get so determined to fix our issue that it can be right in front of our face and we can’t see it. If everything else hasn’t worked up to this point walk away for an hour or so. Calm, down. Then start over from step one.

Any one will tell you that a good debugger equals an awesome programmer. Some people just have a knack for it, but we’re not all born with the goods to breeze right through each issue.

That’s why, like anything else, debugging practice makes perfect. You’ll come up with your own methods and techniques, and along with these you’ll be unstoppable. After a while you’ll start to smell what type of problem you’re running across as soon as you see it, then from there you will notice patterns in different languages and systems you work with so that even when you are working on something new it doesn’t take you all day to debug.

You just can’t give up quickly and ask someone else to do it, or you’ll never learn for yourself. Happy debugging!

Sara Chipps is a software programmer specializing in ASP.NET/C#/SQL. Her blog is Girl Developer.

Subscribe to Data Insider

Learn the latest news and best practices about data science, big data analytics, artificial intelligence, data security, and more.

Similar articles

Get the Free Newsletter!

Subscribe to Data Insider for top news, trends & analysis

Latest Articles