| > - assign (scenario, subsystem, level, description) to breakpoints and watches, so they can be turned on/off or selected in groups for debugging without removal? In Jetbrain's tools they definitely can. I can * create a bunch of breakpoints * give them descriptions * only have them break on execution under certain conditions (conditions stated via the programming language being debugged, so `my_struct.some_func() == 5`) * disable and enable breakpoints with a click of a button * have a breakpoint only become active when another breakpoint got hit (and therefore only cause the debugging logic to execute in certain code paths * Have a breakpoint not stop execution when it gets hit, which is useful because I can then * Log when a breakpoint gets hit, including it's stack trace (so I can see exactly the flow that got me to that breakpoint) * Evaluate some variable when a breakpoint is hit and log that evaluation. All of this with an extremely simple UI that can be manipulated without any recompiles and while the application is running. I've gotten tons of value of debugging complex scenarios in both C# and Rust via this constructs. So while I'm not going to convince you that debuggers are worthwhile, to call them "too dumb to be useful" is pretty naive. |
