3 ms·

So far I haven't encountered a problem that wasn't caught at compile-time. However, your question prompted me to see if I could set a breakpoint and step throu

by pohl 9y ago

So far I haven't encountered a problem that wasn't caught at compile-time. However, your question prompted me to see if I could set a breakpoint and step through a program, and I was able to do it without much effort. I have the "LLDB Debugger" extension in VSC installed. After that, the trick was to configure its launch.json to have the "program" property set to "${workspaceRoot}/target/debug/mandelbrot". That's all it took. Maybe I'd encounter some shortcoming trying to actually use it in anger, but I was happy to be able to do this much.

shabbyrobe 9y ago
This is encouraging! In my experience, getting to this stage - where you've actually seen the thing successfully hit a breakpoint - is 95% of the hard work with debugging. I'm not a heavy debugger user, I prefer trace logging, rich type systems and tests for most problems, but then that one time when you have no choice but to "use it in anger", it simply has to be there. I seem to run afoul of some obscure, ungooglable edge case almost every time I try to start a debugger I don't use very often, regardless of the platform. Of course this happens when I'm frustrated enough to be considering using a debugger in the first place, which is exactly when you don't want to be rage-googling why your debugger refuses to print symbol names, but only when you start it with exactly the arguments you need to start it with to trigger the bug. Or when you try to send an email more than 500 miles away Or print on a Tuesday. By that point, your debugger problem is worse than your original bug. There's a strong sense from a vocal portion of the software development community that debuggers aren't really needed (not suggesting that this is you, just a general observation). Coupled with the fact that building a functioning debugging tool is no easy task, we end up in a situation where far too many platforms treat debugging as a second class citizen when it's really an essential feature, even if for some of us it's a feature of last resort.

by pohl 9y ago

shabbyrobe 9y ago

This is encouraging! In my experience, getting to this stage - where you've actually seen the thing successfully hit a breakpoint - is 95% of the hard work with debugging. I'm not a heavy debugger user, I prefer trace logging, rich type systems and tests for most problems, but then that one time when you have no choice but to "use it in anger", it simply has to be there. I seem to run afoul of some obscure, ungooglable edge case almost every time I try to start a debugger I don't use very often, regardless of the platform. Of course this happens when I'm frustrated enough to be considering using a debugger in the first place, which is exactly when you don't want to be rage-googling why your debugger refuses to print symbol names, but only when you start it with exactly the arguments you need to start it with to trigger the bug. Or when you try to send an email more than 500 miles away Or print on a Tuesday. By that point, your debugger problem is worse than your original bug. There's a strong sense from a vocal portion of the software development community that debuggers aren't really needed (not suggesting that this is you, just a general observation). Coupled with the fact that building a functioning debugging tool is no easy task, we end up in a situation where far too many platforms treat debugging as a second class citizen when it's really an essential feature, even if for some of us it's a feature of last resort.