Why is debugging better in an IDE?

Some examples of some abilities that an IDE debugger will give you over trace messages in code:

• View the call stack at any point in time, giving you a context for your current stack frame.
• Step into libraries that you are not able to re-compile for the purposes of adding traces (assuming you have access to the debug symbols)
• Change variable values while the program is running
• Edit and continue - the ability to change code while it is running and immediately see the results of the change
• Be able to watch variables, seeing when they change
• Be able to skip or repeat sections of code, to see how the code will perform. This allows you to test out theoretical changes before making them.
• Examine memory contents in real-time
• Alert you when certain exceptions are thrown, even if they are handled by the application.
• Conditional breakpointing; stopping the application only in exceptional circumstances to allow you to analyse the stack and variables.
• View the thread context in multi-threaded applications, which can be difficult to achieve with tracing (as the traces from different threads will be interleaved in the output).

In summary, print statements are (generally) static and you'll need to re-compile to get additional information if your original statements weren't detailed enough. The IDE removes this static barrier, giving you a dynamic toolkit at your fingertips.

When I first started coding, I couldn't understand what the big deal with debuggers was and I thought I could achieve anything with tracing (granted, that was on unix and the debugger was GDB). But once you learn how to properly use a graphical debugger, you don't want to go back to print statements.

• An IDE debugger lets you change the values of variables at run-time.

• An IDE debugger lets you see the value of variables you didn't know you wanted to see when execution began.

• An IDE debugger lets you see the call stack and examine the state of the function passed weird values. (think this function is called from hundreds of places, you don't know where these weird values are coming from)

• An IDE debugger lets you conditionally break execution at any point in code, based on a condition, not a line number.

• An IDE debugger will let you examine the state of the program in the case of an unhandled exception instead of just crapping out.

Here's one thing that you definitely cannot debug with "print" statement, which is when a customer brings you memory dump and says "your program crashed, can you tell me why?"

• Print statements all through your code reduces readability.
• Adding and removing them for debug purposes only is time consuming
• Debuggers track the call stack making it easy to see where you are
• Variables can be modified on the fly
• Adhoc commands can be executed during a pause in execution to assist diagnosing
• Can be used IN CONJUNCTION with print statements : Debug.Write("...")

I think debugging using print statements is a lost art, and very important for every developer to learn. Once you know how to do that, certain classes of bugs become much easier to debug that way than through an IDE. Programmers who know this technique also have a really good feel of what's useful information to put in a log message (not to mention you'll actually end up reading the log) for non-debugging purposes as well.

That said, you really should know how to use the step-through debugger, since for a different class of bugs it is WAY easier. I'll leave it up to the other excellent answers already posted to explain why :)

Off the top of my head:

1. Debugging complex objects - Debuggers allow you to step deep into an object's innards. If your object has, say, an array of array of complex objects, print statements will only get you so far.
2. The ability to step past code - Debuggers will also allow you to skip past code you don't want to execute. True, you could do this manually as well, but it's that much more code you have to inject.

As alternative to debug in IDE you can try great Google Chrome extension PHP Console with php library that allows to:

• See errors & exception in Chrome JavaScript console & in notification popups.
• Dump any type variable.
• Execute PHP code remotely.
• Protect access by password.
• Group console logs by request.
• Jump to error file:line in your text editor.
• Copy error/debug data to clipboard (for testers).

I haven't been developing for nearly 20 years, but I find that using a IDE / debugger I can :

• see all kinds of things I might not have thought to have included in a print statement
• step through code to see if it matches the path I thought it would take
• set variables to certain values to make code take certain branches

One reason to use the IDE might be that modern IDEs support more than simple breakpoints. For example, Visual Studio offers the following advanced debugging features:

• define conditional breakpoints (break only if a condition is met, or only on the n-th time the statement at the breakpoint is executed)
• break on an unhandled exception or whenever a (specific) ecxeption is to be thrown
• change variable while debugging
• repeating a piece of code by setting the next line to be executed
• etc.

Also, when using the debugger, you won't have to remove all your print statements once you have finished debugging.

One thing that I'm surprised I haven't seen in another answer is that the 2 debugging methods are not mutually exclusive.

printf debugging can work quite nicely even if you're using a standard debugger (whether IDE based or not). In particular with a logging framework so you can leave all or most of in the released product to help with diagnosing customer problems.

As noted in pretty much all the other answers here, the key nice thing about a standard debugger is that it allows you to more easily examine (and potentially change) the details of the program state. You don't have to know up front what you might want to look at - it's all available at your fingertips (more or less).

This is what I use most on VS.NET debugging windows:

• Call stack, which is also a great way to figure out someone else's code
• Locals & Watches.
• Immediate window, which is basically a C# console and also lets me change variable contents, initialize stuff etc.
• The ability to skip a line, set the next statement to be executed somewhere else.
• The ability to hover over variables and have a tool-tip showing me their values.

In summary, it gives me a 360 degree view of the state of my executing code, not just a small window.

Never found a book teaching this kind of stuff, but then again, it seems to be quite simple, it's pretty much WYSIWYG.

Because debugging multi-threaded applications with print statements will drive you bananas. Yes you can still do it with print statements but you'd need a lot of them and unravelling the sequential print out of statements to emulate the multi-threaded executiong would take a long long time.

Human brains are only single-threaded unfortunately.

Advantages of a debugger over a printf (note not an IDE debugger but any debugger)

1. Can set watchpoints. This is one of my favourite ways of finding memory corruptions

2. Can debug a binary that you can't recompile at the moment

3. Can debug a binary that takes a long time to recompile

4. Can change variables on the fly

5. Can call functions on the fly

6. Doesn't have the problem where debug statemenets are not flushed and hence timing issue can not be debugged acuratly

7. Debuggers help with core dumps, print statements dont'

Since you asked for pointers to books... As far as Windows debugging goes, John Robbins has several editions of a good book on Windows debugging:

Debugging Applications for Microsoft .NET and Microsoft Windows

Note that the most recent edition (Debugging Microsoft .NET 2.0 Applications) is .NET only, so you might want an older one (like in the first link) if you want native code debugging (it covers both .NET and native).

I personally feel the answer is as simple as "A integrated debugger/IDE gives you a wealth of different information quickly without the need for punching in commands. The information tends to be there in front of you without you haven't tell it what to show you.

The ease in which the information can be retrieved is what makes them better than just command-line debugging, or "printf" debugging.

• A debugger can attach to a running process

• Often easier to debug threaded code from a debugger

With an IDE debugger you can see the values of ALL the variables in the current scope (all the way up the call stack) whenever you halt execution.

Print statements can be great but dumping so much information to the screen at any given place can produce a whole lot of print statements.

Also, many IDE debuggers let you type in and evaluate methods, and evaluate members while you are halted, which further increases the amount of print statements you'd have to do.

I do feel that debuggers are better for some languages than for others however...

My general opinion is that IDE debuggers are absolutely, amazingly wonderful for managed languages like Java or C#, are fairly useful for C++, and are not very useful for scripting languages like Python (but it could be that I just haven't tried a good debugger for any scripting languages yet).

I absolutely love the debugger in IntelliJ IDEA when I do Java development. I just use print statements when I use Python.

As someone said above: Debugger != IDE.

gdb and (back in the day) TurboDebugger (stand-alone) work just fine for the languages they support[ed], thank you. (or an even older technology: Clipper debugger linked into the xBase executable itself) -- none of these required an IDE

Also, though C/++ coding is more rare, printf statements sometimes mask off the very bug you are trying to find! (initialization problems in auto vars on the stack, for instance, or memory allocation/alignment)

Finally, as others stated, you can use both. Some real-time-ish problems almost require a print, or at least a judicious "*video_dbg = ( is_good ? '+' : '-');" somewhere into video memory. My age is showing, this was under DOS :-)

TMTOWTDI

In addition to much of what the other posters have said, I really like stepping through one line at a time along with the computer, as it forces me to think about one line at a time. Often I will catch the bug without even looking at variable values simply because I am forced to look at it as I click the 'next line' button. However, I don't think my answer will help you, Bill, because you probably have this skill already.

As far as learning resources go, I haven't used any -- I just explore all the menus and options.

Is this even real question from real programmer?

Anyone who spent even 5 mins debugging with print statements and debugging with IDE - it will OCCUR to him/her without even asking!

I've used both prints and IDEs for debugging and I would much rather debug using an IDE. The only time for me when that doesn't work is in time critical situations (like debugging online games) where you litter the code with print statements and then look at the log files after it has gone horribly wrong. Then if you still cannot figure it out, add more prints and repeat.

Well another thing is that if you join a new old project and nobody really knows how the code is doing what it's doing, then you can't debug by echoing variables/objects/... b/c you have no idea what code is executed at all.

At my job I am facing exactly that kind of situation and visual XDebuging helps me getting an idea about what is going on and where, at all.

Best regards

Raffael

It's not just debugging. An IDE helps you build better software faster in a lot of ways:

• refactoring tools
• intellisense to make api's more discoverable, or remind of exact spelling/case of familiar items(not much use if you've used the same system for 15 years, but that's rare)
• save on typing by autocompleting variable and class names
• find certain kinds of errors before you even start to compile
• Automatically jump to variable/method/class declarations/definitions, even if they're not in the same file or folder.
• Break on unhandled and handled exceptions

I could go on.