Actually this is a list of "Breakpoint actions" where when breakpoint is reached it doesn't stop but rather continues to do some action and then run continues as usual.

While debugging you add instructions like setting variables with values and even skipping from one location to another and setting next instruction.

Perhaps you can mark code that is being skipped (similar to commenting it out) and have the debugger notify (simmilar to console.out or even send a popup message).

Then when you want to re-run the whole thing, it automates the debugging run.
-- pashute, Jan 16 2008

I don't quite understand this idea, but I remember from long hours debugging commercial code by various shops that in general you can comment out anything which throws an error and there is no noticeable difference in software performance. It is surprisingly rare that you comment out something which actually does something important.
-- vincevincevince, Jan 16 2008


I don't get it either. How can you debug code you don't run?

Does it help that Visual Studio has a "TRY / CATCH / FINALLY" command that attempts to execute an instruction and can execute alternate code if the inital TRY fails?
-- phoenix, Jan 16 2008


GDB already has the ability to execute commands when a breakpoint is hit. I don't use IDEs, so I can't speak for them.
-- Srimech, Jan 16 2008



random, halfbakery