Is it possible to Edit and Continue in Visual Studio 2010 without pausing execution? - visual-studio-2010

I recently watched a bit of Notch's Ludum Dare live stream. He uses Eclipse's hotswap feature extensively while he works on his game. (here is a video of what I am referring to http://www.twitch.tv/notch/b/302823358?t=86m30s)
I would like to do the same with C# and XNA. Fortunately, Visual Studio has an Edit and Continue feature. However, I would like to edit my rendering code while it is running instead of pausing it.
Is it possible for me to setup Visual Studio to do the same? I noticed that there is a checkbox for Break all processes when one process breaks. Is it maybe possible to set up my rendering loop in another thread so that the game keeps rendering while I make a change?

Update: This answer is now available as a video.
I've been struggling to find a way to do this. I know this doesn't answer your exact question. But really what you are looking for is a workflow where you can make code changes with zero (or near-zero) delay, and I think I've figured out the closest you can get with just Visual Studio. (And therefore avoiding a huge engineering effort and dealing with "abnormal" projects).
The way to achieve this workflow is actually astonishingly simple, once you think of it:
Use shortcut keys!
The first way I came up with is to just use the normal edit-and-continue method of setting a breakpoint. Only by using the keyboard you can do this considerably faster. This only works with code being called in a loop (eg: draw/update). Click the code you want to modify, add a breakpoint (F9), the breakpoint will almost immediately be hit, modify your code, remove the breakoint (F9), and then run the code again (F5).
This is pretty good. You don't have to use the mouse to hit the relatively small "Add breakpoint" target in the left hand column. But it does move the input focus to the beginning of the line, so you generally have to use the mouse again to fix that before you can start editing.
I want something faster. So I came up with a better solution:
Again, using the keyboard: Press Ctrl + Alt + Break to "Break All". This enters the debugger almost instantly, without having to worry about setting a breakpoint or if the code you want to modify is running in a loop. This will change the editor window and caret focus to the document where execution break, but you can then immediately fix it by pressing Ctrl + - for "Navigate Backwards".
Then you can make your edits and simply press F5 to see them in action. You only have to use the mouse once (or not at all) to initially pick where you want to start typing - just as you would expect.
Admittedly Ctrl + Alt + Break and Ctrl + - are horrible key combinations for something you want to be able to do extremely quickly. And it would be better if there was just one key to press.
If you have the full Visual Studio, you could probably turn it into a macro or add-in. Express doesn't have those - so the best you can do is modify your key bindings (Tools, Customise, Keyboard...) and bind it to two keys that are adjacent, that you can press in quick succession. Or use an external macro utility.
Personally I have set up the two key combinations to be pressed in succession (you don't seem to need a delay between the two) by a macro set to a spare button on my mouse. Which works reasonably well - as I'm usually selecting text at the same time. I might add a keyboard macro later too.
So far I've identified two minor pitfalls of this method:
When you run the app again, Visual Studio gives it focus. It would be nice if it kept focus. Adding a left mouse click to my macro is a partial solution to quickly re-editing code.
"Navigate Backwards" does not retain the text selection, only the caret position.

i can tell you how, but you arn't going to like it:
1) run your game executable in a visual studio instance (game.exe --> vsInstanceA)
2) code your modifiable code in a seperate dll, using a seperate visual studio instance (modifiable.dll --> vsInstanceB)
*note that doing this lets you compile your modifiable.dll, thus doing compile time error checking, etc.*
... and now is where it get's tricky ...
3a) game.exe needs to reference the modifiable.dll. NOT the .vcproj, the actual dll
3b) when you hit a "magic key" (have game.exe look for a key-press), have game.exe unload the modifiable.dll, and reload it. You can easily do this via the Assembly and AppDomain classes provided in mscorlib. Of course this means you need to unload any dependant systems in game.exe.
note, there's a lot of hand-waving in this 3b) section, it's quite a lot of work but pretty straight forward (example google search: https://www.google.com/search?q=dynamic+load+dll+.net)
... and after that, you are good to go ...
3-alt) some other choices if 3b) doesn't suit you:
you can invoke msbuild.exe to rebuild modifiable.dll when you press
"magic key"
you can use the CSharp compiler dll's to dynamically
recompile each class instead of the entire modifiable.dll
but unfortunatly, in my 10+ years of .net development, this is the only way, unless someone has created a 3rd party product to do it (IE: they do what i mentioned, for you)

This may not be exactly what you're looking for but it's what I've been doing. Just throw in a break point while your game is running. Once it's stopped, you can edit things, remove the break point, and then hit F5 to continue.
For the most part, this allows you to edit things while the game is running and continue running the game afterwards but it doesn't work for everything. You can't add or remove class level things and also can't add/remove entire functions or the parameters. Mostly, I do this to test out different numbers and equations for smaller things that get hit every update.

To answer the original question "in Visual Studio 2010 without pausing execution?"
No. For Java there is JRebel which allows this.
I can quickly imagine why Microsoft haven't done this - if you have some sort of committee or group of people designing things - it's easy for even one person to come up with good arguments where this "dynamic software updating"/hotswap will break. It's just too easy to shoot down. Or if they proceed with it, it will be through some entirely new "enterprise framework" that requires lot of steps, work and understanding to get anywhere, because they want to use it for complicated online scenarios.
I'd prefer there was some simple way to do this - I'll take the risks, and put up a lot of disclaimers that if you want hotswap services that talk to external systems then you need to use that complicated framework or whatever.
The most typical scenario where this could safely be used with low risk is prototyping and tweaking some sort of engine with either high startup cost or more likely, to study behaviour if something running in the engine (like rules) is buggy and to exhibit the bug, a lot of things has to happen and it's possible you don't encounter the bug always. That is the case where having this could save weeks of debugging time, atleast would have in my case.

I'm used to work in Java using IntelliJ Idea + DCEVM (Dynamic code evolution VM).
Unfortunately i haven't found anything getting closer to that configuration at Microsoft C# platform. It really sucks and you can't do much about it. You can use some user defined macros, but you can't still do much in Edit and Continue mode without restarting Debug session).
However if you can, try to use newest .NET Core which offers much better productivity using Dotnet Watch. Still not so fast as DCEVM but much better than traditional VS + .NET hot reload experience. Details here.

Related

How do i get Visual Studio 2015 to highlight brackets, braces and references instantly, with no delay?

When placing the curser on a closing bracket in c# for instance, there is a small annoying delay before the opening bracket gets highlighted, and you have to sit and wait before you can use shortcuts such as (ctrl + shift + up/down). It feels like it is intended behaviour for reasons beyond me, so i don't think it is a bug or because my computer is slow (it's not), but it's driving me crazy.
I'm on a freshly installed PC, so i have only testet it in a few programming languages / file formats, and the behaviour only occours in some of them.
The delayed highligh behaviour occurs in .cs (c#), and .css files, but not in .js and .html files, here the code gets highlighed instantaneously exactly like i want it to in .cs files aswell.
I'm using Visual Studio 2015 Community Edition.
I have had this problem as well, since first installing. I can confirm that Update 1 CTP addresses this issue, and the delay is almost gone (maybe 1/8 second now.)
This UI delay was actually called out as a bugfix that was included with the update:
https://support.microsoft.com/en-us/kb/3025135
To the problem that there is a delay highlighting the brackets: In my opinion that has nothing to do with a bug. I think it takes a little while because your code needs to be parsed every time you change something in order to highlight the brackets. When you have many lines of code in one file it is obvious that it takes a little more time than normal.
Here are some tips that may help you:
Click the bracket and press STRG + ´ this will bring you directly to the other bracket. Or you press ALT + ´ and it will mark all your code in between your current brackets. You can look up the shortcuts of Visual Studio in Tools -> Options -> Environment -> Keyboard:
I'd recommend everybody programming in Visual Studio is to change the highlight color of the matching bracket. Have a look at this:
Here you can change all the colors and forms used for specific searchterms. I personally use Visual Assist 2015 to highlight my code (that's why I didn't change anything here). It is way more faster than VS itself and comes with a lot more functions like bracket guidelines who will show you the indent level of your brackets. Have a look, maybe you like it:
Its about 500ms in a newly created console project
500 msec is a magic number in .NET. You can get some insight from the source code for the C# Language Service, accidentally (?) exposed by a Microsoft programmer on github. Most relevant file is probably this one:
internal interface IBraceMatchingService
{
Task<BraceMatchingResult?> GetMatchingBracesAsync(Document document,
int position, CancellationToken cancellationToken = default(CancellationToken));
}
Or in other words, the brace matching service runs as a background task. Such tasks normally run on a thread-pool thread and are subject to scheduling by the threadpool manager. That's where the magic 500 ms number comes into play. The manager attempts to keep the number of executing tp threads down to the number of processor cores available on the machine, the most efficient way to run threads. However, if the existing tp threads take too long to finish their job then the manager assumes that they are bogged down by I/O and allows an extra one to run. It does this once every 500 msec.
So first-order estimate of your problem is that VS has too many active thread-pool threads and they don't complete in a timely manner. Causing the brace matching task to run too late.
Finding out exactly what specific tasks bog it down is technically possible. I can't guarantee success with the Community edition and you'd need a fair amount of insight in how to read thread call stacks to get ahead. Startup another instance of Visual Studio and use Debug > Attach to Process. Pick "devenv.exe" from the list. Let it trundle while it is attempting to find PDB files, then use Debug > Break All.
First place to look is Debug > Windows > Tasks. Pretty unlikely you'll see anything there however, normal is to see none. Next one is Debug > Windows > Threads. You ought to see about 15 active threads back in that window. Hover over their Location column to take a peek at their callstack. Making sense of what you see isn't that simple unfortunately, it will help a lot if you can compare what you see with another machine that does not have this problem.
Since you have this problem on more than one machine, another approach is to look for an environmental factor that they have in common. Things to look for are aggressive anti-malware, a network connection that is too slow or too unreliable, a poorly performing add-in that you like but runs poorly on a VS version it wasn't tested on.
And consider that VS2015 isn't exactly ready for prime-time. Of all the recent VS versions released in the past 18 years, it is probably the least stable. It has a lot of heavy internal changes and there were an unprecedented number of alpha and beta versions with critical bug fixes implemented just a few months ago. Try it again after Update 1 is released.
Seems like this will be fixed in a future Visual Studio update: https://github.com/dotnet/roslyn/issues/1906#issuecomment-145874647
I have not found a definitive solution for your problem.
This was a known bug in the VS2015 review edition.
This links discusses the delay (this link refers to c# btw, not c):
https://connect.microsoft.com/VisualStudio/feedback/details/1033540/braces-are-not-highlighted-correctly-in-c
And there are still similar problems for some VS2015 Community Edition users.
http://www.developerteacher.com/msdn/bracket-matching-highlights-not-working-like-i-had-in-2013-express-4227
Personally, I think you are stuck with a bug and if I were you I'd try the following:
Make sure I had unistalled all previous editions of VS.
Try a repair.
Completely uninstall and reinstall VS2015 if running repair doesn't work
Go back to VS2013 if it drives you cannot stand it, and wait until VS2015 is a bit more ripe on the vine.
One thing I have found with VS, is when it plays up it's painful, it takes so long to install and the worst case was when I ended up uninstalling and downloading everything that was associated with the install. It now works fine. (this was after previewing 2015 and then going back to 2013). You can also try this for VS2015 and also try a new download.
I sometimes will have a look at some previews, but after jumping in with haste too many times with the latest software releases and then repenting with leisure. I am now happy to wait for new releases to be out for a while before upgrading.
Another FYI for you to browse.
This is a link to Visual Studio 2015 RC fixed bugs and known issues. There are quite a few issues and hacks suggested. (not specific to your problem, but still there a few months ago.).
I am assuming you know how to play around with the settings. I've added the obvious, in case it's been overlooked.
I have added this screen shot from VS2013 settings.
Make sure you have automatic delimeter highlighting checked.
Sorry I could not be of more help.

Can VS 2013 show me a visual representation of the path my code takes as I take it?

When I'm debugging, Visual studio allows me to place a breakpoint anywhere, which in turn allows me to step through the code. However, I sometimes encounter a problem where what I THINK is the first method called, actually isn't the first method called. For example, I THINK the onclick for my button is called first, but actually, it's another method on the Master page, or even something in my Global.asax, which then changes a variable, which then changes the code path my code takes, which then breaks my code.
I'm looking for something that's basically: press this button in Visual Studio while debugging, then do something that causes a postback (or otherwise something to happen in the backend), and Visual studio then automatically goes to the very first method called and starts stepping through the code at a steady but understandable pace (longer method calls notwithstanding, and only going through my own code, not anything in library references) until you tell it to stop.
I know this sounds like profiling, but it's actually not. Profiling just passively gathers data while you do your thing, and shows it afterwards. There's no live feedback on what happens, and I can't make heads nor tails of the result of the profiler. In fact, last time I used the built-in VS profiler, one of my top 3 intensive methods was the profiler itself, if I read it correctly.
Ideally, what I want is something that looks and feels like an automatic debugger, something that goes F11 every .5 seconds, but skips external DLLS.
Does such a thing exist?
Runtime Flow extension (developed by me, 30-day trial) can show you paths the code takes in real time. Thought it is separate from VS debugging and requires some manual configuration for ASP.NET projects.
This is a ridiculously complicated requirement. I'm not saying it's a bad idea, and it would be amazing if such a thing was possible, but I very much doubt it's available anywhere. I've never heard of anything like this as a VS feature or even as a plugin.

Does Visual Studio have "break where you are" functionality?

We have started encountering endless loops in our engine recently and I have no idea how to effectively fight them. The app simply freezes for eternity and I am unable to stop it's execution to understand what is going on. Placing normal breakpoint in major places (update loop) does nothing. I am almost certain that the problem is in a continuously running loop somwhere, but due to the code's size I cannot even start guessing where to look for it.
So, my question is how do you break app's execution in Visual Studio at some arbitrary place in the code, where the app happens to be at that time? Something akin to "stay where you are". Is it even theoretically possible?
Sure, use Debug + Break All.
This of course doesn't necessarily break your program at a nice address that happens to match one of the statements in your program. Pretty likely if setting breakpoints didn't invoke a break. You are likely to see a notification from the debugger that it cannot display source code. Or for that matter, it might not have selected the correct thread.
So first thing you want to do is use Debug + Windows + Threads and make sure that the correct thread is selected. Double-click the one you want to debug. Next thing you want to do is look at the Debug + WIndows + Call Stack window. It should at least display some of your methods, giving you a hint how it ended up in never-never land.
And it isn't unlikely that it got deadlocked on native code or an operating system call. To see that, you'll need to enable unmanaged debugging. Project + Properties, Debugging, tick the "Enable native code debugging". And make sure you've got the symbol server enabled so you'll get debugging info for the operating system DLLs. Tools + Options, Debugging, Symbols.

Historical debugging

I have to debug a very big program, which takes around 10 minutes until it reaches the most important debugging state. I just want to modify some values in this part of the program, but sometimes I would like to go back and modify them again, like travelling to the past. As far as I know it is called historical debugging. Reading some info it seems it has been implemented in Visual Studio 2010. But I only use Eclipse or Xcode or vi :)
I wonder if know some other software with these capabilites.
By the way, I ask about your opinion, do you think it will be possible, once I reach this state of my program, to modify some small part of the code, after the breakpoint, and compile it again (supposing it does not affect to the past execution and code) so I can test it without recompiling?
Thanks
Also discussed here
Mostly only available for interpreted languages like Java (ODB). And I am not sure if you can continue from some point of execution with changed data.
Have you tried to set watch point in Eclipse that would break as soon as a variable reach a specific value? This means your code executes normally until it breaks your data and execution stops so that you can see how you code got to this point.

Why is debugging better in an IDE? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I've been a software developer for over twenty years, programming in C, Perl, SQL, Java, PHP, JavaScript, and recently Python. I've never had a problem I could not debug using some careful thought, and well-placed debugging print statements.
I respect that many people say that my techniques are primitive, and using a real debugger in an IDE is much better. Yet from my observation, IDE users don't appear to debug faster or more successfully than I can, using my stone knives and bear skins. I'm sincerely open to learning the right tools, I've just never been shown a compelling advantage to using visual debuggers.
Moreover, I have never read a tutorial or book that showed how to debug effectively using an IDE, beyond the basics of how to set breakpoints and display the contents of variables.
What am I missing? What makes IDE debugging tools so much more effective than thoughtful use of diagnostic print statements?
Can you suggest resources (tutorials, books, screencasts) that show the finer techniques of IDE debugging?
Sweet answers! Thanks much to everyone for taking the time. Very illuminating. I voted up many, and voted none down.
Some notable points:
Debuggers can help me do ad hoc inspection or alteration of variables, code, or any other aspect of the runtime environment, whereas manual debugging requires me to stop, edit, and re-execute the application (possibly requiring recompilation).
Debuggers can attach to a running process or use a crash dump, whereas with manual debugging, "steps to reproduce" a defect are necessary.
Debuggers can display complex data structures, multi-threaded environments, or full runtime stacks easily and in a more readable manner.
Debuggers offer many ways to reduce the time and repetitive work to do almost any debugging tasks.
Visual debuggers and console debuggers are both useful, and have many features in common.
A visual debugger integrated into an IDE also gives you convenient access to smart editing and all the other features of the IDE, in a single integrated development environment (hence the name).
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:
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.
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.
In my experience, simple printouts have one huge advantage that no one seems to mention.
The problem with an IDE debugger is that everything happens at real time. You halt the program at a certain time, then you step through the steps one at a time and it is impossible to go back if you suddenly want to see what happened before. This is completley at odds with how our brain works. The brain collects information, and gradually forms an oppinion. It might be necessary to iterate the events several times in doing so, but once you have stepped past a certain point, you cannot go back.
In contrast to this, a selected series of printouts/logging gives you a "spatial projection of the temporal events". It gives you a complete story of what happened, and you can go back and fourth several times very easily by just scrolling up and down. It makes it easy to answer questions like "did A occur before B happened". It can make you see patterns you wernt even looking for.
So in my experience. IDE and debuggers are fantastic tools to solve simple problems when something in one single call-stack went wrong, and explore the current state of the machine at a certain crash.
However, when we approach more difficoult problems where gradual changing of state is involved. Where for example one algorithm corrupted a data structure, that in turn caused anohter algorithm to fail. Or if we want to answer questions like "how often do this happen", "do things happen in the order and in the way as I imagine them to happen". etc. Then the "old fashined" logging/printout technique has a clear advantage.
The best things is to use either technique when it is most suitable, for example use logging/printouts to get to some bugs, and pause at a breakpoint where we need to explore the current state more in detail.
There are also hybrid approaches. For example, when you do console.log(object) you get a data-structure widget in the log that you can expand and explore more in detail.This is many times a clear advantage over a "dead" text log.
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).
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.
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.
Advantages of a debugger over a printf (note not an IDE debugger but any debugger)
Can set watchpoints.
This is one of my favourite ways of finding memory corruptions
Can debug a binary that you can't recompile at the moment
Can debug a binary that takes a long time to recompile
Can change variables on the fly
Can call functions on the fly
Doesn't have the problem where debug statemenets are not flushed and hence timing issue can not be debugged acuratly
Debuggers help with core dumps, print statements dont'
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.
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.
Just wanted to mention a useful feature of a console debugger vs printf and vs debugger in an IDE.
You can attach to a remote application (obvioustly, compiled in DEBUG mode) and inspect its state dumping the debugger output to a file using POSIX tee utility. Compared to printf, you can choose where to output the state in run-time.
It helped me a lot when I was debugging Adobe Flash applications deployed in an agressive environment. You just need to define some actions that print required state in each breakpoint, start the console debugger with fdb | tee output.log, and walk through some breakpoints. After that you can print the log and analyse the information by thorough comparison of the state in different breakpoints.
Unfortunatelly, this feature [logging to a file] is rarely available in GUI debuggers, making developers compare the state of objects in their head.
By the way, my opinion is that one should plan where and what to debug before staring a debugger.
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
In addition to the many things that have been already mentioned, one of the most important advantages of a debugger over printf is that using printf statements assumes that you know in which function the bug resides. In many cases you don't, so you have to make a few guesses and add print statements to many other functions in order to localise it. The bug may be in framework code or somewhere far removed from where you think it is. In a debugger it is far easier to set breakpoints to examine the state in different areas of the code and at different points in time.
Also, a decent debugger will let you do printf-style debugging by attaching conditions and actions to breakpoints, so that you still retain the benefits of printf debugging, but without modifying the code.
Debugging in an IDE is invaluable in an environment where error logs and shell access are unavailable, such as a shared host. In that case, an IDE with a remote debugger is the only tool which allows you to do simple things such as view stderr or stdout.
A problem with using print statements is it makes a mess of your code. IE, you have a function with 10 parts to it and you know it crashes somewhere, but you're not sure where. So you add in 10 extra print statements to pinpoint where the bug is. Once you've found and solved your bug, you now have to clean up by removing all of those print statements. Maybe you'll do that. Maybe you'll forget and it'll end up in production and your user's console will be full of debug prints.
Wauw, do I like this question. I never dared to pose it...
It seems that people just have different ways of working.
For me what works best is:
Having a solid mind model of my code, including memory management
Using instrumentation (like print statements) to follow what's happening.
I've earned my living programming for over 40 years now, working at non-trivial technical and scientific applications in C++ and Python daily, and I have the personal experience that a debugger doesn't help me a bit.
I don't say that's good. I don't say that's bad. I just want to share it.
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.

Resources