Sometimes there’s literally no other way (that I know of). When you’re debugging concurrency issues, stopping all time with a debugger just isn’t an option.
I guess, there’s technically nothing which dictates that a debugger has to work by stepping through a program. It could also present you some diagram of variable values changing over time. But yeah, gonna be hard to find a more useful representation than those values being interleaved with your logs, at least for most applications. I have heard of more advanced debuggers being used in gamedev, which makes sense, since logs aren’t nearly as useful there.
But yeah, given that most people think of the stepping debuggers, them being the default advice does feel emblematic of our industry still shying away from concurrency.
I can also see the variables change by logging them.
Debuggers are great if you want to see in detail what’s going on in a specific loop or something, but across a big application with a framework that handles lots of things in unreadable code, multiple components modifying your state, async code, etc.; debuggers are a terrible way to track what’s going on.
And often when I’ve found where it goes wrong, I want to check what was happening in a previous bit of code, a previous iteration or call. Debuggers don’t go back; you have to restart and run through the whole thing, again finding exactly where it went wrong, but now just a bit before that, which is often impossible.
With logging, you just log everything, print a big warning where the thing has gone wrong, and scroll back a bit.
Debuggers are a fantastic bit of technology, but in practice, simple logging has helped me far more often. That said, there are issues where debuggers do beat logging, but they’re a small minority in my experience. Still useful to know both tools.
I mean, you should do general logging either way, since you won’t have a debugger attached when running in production. And then you can typically scroll back in the logs, too, when the debugger has paused execution.
What this meme is talking about, is adding ad-hoc logs to narrow down where an error occurs while developing. So, bullshit logs like console.log("1"), followed by a line of potentially bad code and then console.log("2”). Log lines which you’ll remove again when you’re done debugging…
This does sound very interesting. I should have said the debuggers I’m familiar with don’t do it. Or if they do, I have no idea how.
Certainly setting breakpoints on certain conditions instead of just a line, would help a lot. Being able to step backwards through the execution even more so.
Sometimes there’s literally no other way (that I know of). When you’re debugging concurrency issues, stopping all time with a debugger just isn’t an option.
Yep, I’ve had times where the debugger was hiding the race condition that was the actual cause of my problem.
I guess, there’s technically nothing which dictates that a debugger has to work by stepping through a program. It could also present you some diagram of variable values changing over time. But yeah, gonna be hard to find a more useful representation than those values being interleaved with your logs, at least for most applications. I have heard of more advanced debuggers being used in gamedev, which makes sense, since logs aren’t nearly as useful there.
But yeah, given that most people think of the stepping debuggers, them being the default advice does feel emblematic of our industry still shying away from concurrency.
console.log("functionOne", "A", varA, "B", varB, "C", varC);console.log('func', {A, B, C})I can also see the variables change by logging them.
Debuggers are great if you want to see in detail what’s going on in a specific loop or something, but across a big application with a framework that handles lots of things in unreadable code, multiple components modifying your state, async code, etc.; debuggers are a terrible way to track what’s going on.
And often when I’ve found where it goes wrong, I want to check what was happening in a previous bit of code, a previous iteration or call. Debuggers don’t go back; you have to restart and run through the whole thing, again finding exactly where it went wrong, but now just a bit before that, which is often impossible.
With logging, you just log everything, print a big warning where the thing has gone wrong, and scroll back a bit.
Debuggers are a fantastic bit of technology, but in practice, simple logging has helped me far more often. That said, there are issues where debuggers do beat logging, but they’re a small minority in my experience. Still useful to know both tools.
I mean, you should do general logging either way, since you won’t have a debugger attached when running in production. And then you can typically scroll back in the logs, too, when the debugger has paused execution.
What this meme is talking about, is adding ad-hoc logs to narrow down where an error occurs while developing. So, bullshit logs like
console.log("1"), followed by a line of potentially bad code and thenconsole.log("2”). Log lines which you’ll remove again when you’re done debugging…Yes, they do: https://rr-project.org/
https://sourceware.org/gdb/current/onlinedocs/gdb.html/Reverse-Execution.html
This does sound very interesting. I should have said the debuggers I’m familiar with don’t do it. Or if they do, I have no idea how.
Certainly setting breakpoints on certain conditions instead of just a line, would help a lot. Being able to step backwards through the execution even more so.
I wonder if rr would work for this scenario?