As someone who knows how to use a debugger, I can say for sure that log debugging is fine and often my first approach. If you have a good mental model of the code and the issue, it’s usually just 1-2 logs to solve the problem.
I never felt a need to do it some other way
printf(“here”)printf(“here1”)printf(“here2”)
This is the way Although I also like:
File 1:
print(0.1)
print(0.2)
File 2:
print(1.1)
print(1.2)
…Minimal c+p+e effort
Can somebody reupload the image at a non-feddit.org host? Feddit is incredibly annoying in that it geoblocks most of Asia.
There you go
Extremely helpful debugging race conditions
Except when adding the log fixes the race condition.
Yay! Problem solved. 🤓👍
I see you’ve used Knex.
I am guilty of this but for a different reason: setting up debugging for clis in rust is hard
I love the debugger. I use it all the time I can. But when debugging cli it’s a pain as you need to go back in the launch.json file, remake the argument list, then come back to run debug, find out why tf it doesn’t find cargo when it’s the PATH… again, then actually debug.
Meh
alert(“here”);is betterOld school. Also the flip side:
sudo tail -f /<path to server>/error.logTo me logging combined with a quick compilation has a good flow to it. Causes you to consider what you want to see and doesn’t change the workflow if multiple stacks are involved.
It drives me crazy that half my coworkers do this, including a senior dev. I’ll be on a call trying to help debug something and it makes it so difficult not being able to set a breakpoint
I used to do debuggers until I started doing embedded and dipped my feet in multithreading (2 different projects). After many hours lost because the debugger straight lied to me about which line of code has been executed, a colleague suggested that I just do a printf like a filthy beginner. And 🤩it worked🤩 and I never went back to the unreliable world of debuggers. Even though now I’m mostly working with single-threaded python scripts.
There are literally university courses which confidently state “Console logging is far more used and better so we won’t talk about a debugger here”!
Like sure, it’s very likely to be used far more, but that doesn’t mean you shouldn’t at least offer some courses or modules about proper use of a debugger…
I console.dir and debugger; and breakpoint all day. You are allowed to mix your strategies.
console for quick and dirty understanding but inspector for more complex fixes.
This right here. Time and place for both.
Can you set a breakpoint in production two days ago to debug an incident, though?
God, I wish. I’d throw money at whoever could implement such a thing. I guess its actually theoretically possible if you just sort of wrote the whole stack to an HDD but the amount of space that would take up lol.
But yeah, good logging (and not excessive logging!) is also extremely important
Oh this is beautiful
It’s like the real life kraken, I’ve never seen it but the name causes dread.
This is what peak performance looks like:
console.log("before dothething"); let r = dothething(); console.log("after dothething"); console.log(r);Hey how’d you get your hands on my code
