h a l f b a k e r yViva los semi-panaderos!
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
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.
[link]
|
| |
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. |
|
| |
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? |
|
| |
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. |
|
| |