If the wrong answer is coming out, something you 'know' is wrong.Īfter the most obvious failure mode doesn't reveal the problem, your next check may not be the second most obvious failure. Your brain is telling you that based on everything you 'know' about the code, the right answer should come out. The best description I've heard for master-level debugging is that it's a process of narrowing down the problem space as cheaply as possible.
#CLION DEBUGGER HOW TO#
So the majority of us quickly reach a point where we are satisfied that we 'know how to debug' but leave a lot of room for improvement on the table. If you don't believe it's a time suck then you have very little incentive to keep pushing to get better at it.
#CLION DEBUGGER CODE#
Incidentally the same is true with Haskell, moreso even, except due to laziness the evaluation order can be harder to ascertain - debug statements can appear in a strange order (or not at all).Ī lot of us believe that we spend a much smaller portion of our time looking at or debugging existing code than we really do. So I can rely on print-debugging to quickly find the cause of my problem. With the occasional exception of highly generic code, your call sites and function arguments are exactly what you expect. You can't randomly mutate things, you can't (without considerable effort) make complicated graph structures where everything can touch everything else. In contrast, in Rust things tend to happen in a very constrained fashion. In such a situation, I would fire up the debugger and inspect the general state of the application (which Java makes relatively easy to do). Print-debugging is often too narrow to highlight the cause. Maybe I'm not actually calling the function I thought I was, maybe because I have actually received a subclass of my expected class. With Java, I have often found that errors occur in a rather non-local fashion, due to dynamic code loading, confusing inheritance trees, and ubiquitous mutations and what have you. Obviously if there is a segfault, I'd fire up a debugger - GDB is just fine for such purposes. I did specifically mention "normal code". printf debugging in Java that I encounter is usually due to a lack of understanding of what the debugger can do, not for any real benefit. Just that it's far later than most people encounter, when a sophisticated debugger exists. You can do stuff that's infeasible from the outside, it'll always have some place, and some languages/ecosystems give you no option. To be clear, I'm not saying there's never a need for in-bin "debugging" with prints, data collection of some kind, etc. Printing is language agnostic tho, so it's at least a viable fallback in all cases, which does make it a lot more common. Only slightly more complicated than multi-thread since the source isn't all in one UI. Past (legitimately shallow) multi-process debugging that I've done has been pretty easy IMO, you just add a conditional breakpoint on the IPC you want and then enable the breakpoints you care about. But debuggers are definitely more invasive / have stronger side effects, and have no workaround, yea. But so does calling a printing func that does IO, since it often involves system-wide locks - I'm sure many here have encountered bugs that go away when print statements are added. > Your conditional breakpoint can change execution behavior thought flushing cache/icache in a way that doesn't reproduce. When your loops regularly have 100k iterations before they fail on one single iteration, that's a lot of log output to sift though (or a lot of unnecessary loop counters & if-statements) for a rarely-encountered case.
#CLION DEBUGGER FULL#
This would take 3-4 full runs without the debugger.Ĥ.) Ability to set conditional breakpoints and skip all the data that's working properly, only stopping on one particular record. When I find a bug, oftentimes I'll try 3-4 new approaches just by entering watch expressions until I find an algorithm that works well on the data. Aside from the ones you mention, key advantages of a good IDE debugger include:ġ.) Ability to see the value of every variable in scope without needing to decide a-priori which variables are worth looking at.Ģ.) Ability to traverse the call-stack and identify at what point a computation went wrong without having to instrument every single call & variable.ģ.) Ability to interactively try out new code within the context of a stack frame. I do the bulk of my programming in Kotlin these days, and I'd say that the primary reason is because IntelliJ's debugging support is so good.
0 kommentar(er)
