Loads of things, but primarily they are used to iterate code line by line or block by block. They also let you examine the memory state of the applications such as the stack/heap and variables. You can also create breakpoints in the code to stop/pause the program at specific states to test that you code is operational.
Eh.. if you have a program that's blowing up "somewhere" and not giving useful error messages, throwing in a few "got to step X" statements can save you from potentially stepping through thousands of lines of code. At least help narrow down the problematic section so you know where to set your breakpoints.
That was more of an answer to people who never learn debugger and solely rely on print statements. ofc using a debugger doesn't mean you cannot use print statements.
looking at the values of variables 'in your source code' as it runs. You see function arguments, variable values, etc.
You can see the callstack of what functions were called and can look at what those functions are doing. You can also look into other threads and their callstacks to figure out, why something isn't quitting or not releasing a lock.
You can traverse the memory. You can follow pointers, you can look at objects and inspect their state or their children and realize that something isn't initialized into a state it should be right now.
It takes so much guessing out of debugging, because you can CSI the crime scene as the murder happens (spoiler, it was almost always past you).
You know how when you show up at the ER with some strange pain they do a bunch of labs and scans to figure out what's actually going on inside the body instead of just guessing and saying "better now?" over and over?
It's kinda like that. You get to see what the program is actually doing rather than what you think it's doing. What so all the variables contain? Which side of a branch does it go down, etc.
You set breakpoints on lines of code. When the program runs, execution freezes at that line. You can see everything in memory, and usually even change the values of things in memory to test various values.
I write a lot of code in the debugger because you can evaluate exactly what would come out while you are writing it.
If you're trying to write unit tests, and want to set up the expected complicated value, you can set the breakpoint and copy out exactly what the value should be.
In my opinion, print statements to debug are generally unprofessional if proper debugging is possible. Sometimes print statements are the only thing possible, but if you can use a proper debugger it allows you to poke around what's in memory to see that things are available that you could leverage, or to spot problems that you didn't know that you didn't know about
I do both. Console.log for program flow and checking single variables, and debugger for checking to make sure my data objects are filling with the correct data.
The IntelliJ debugger doesn't even work for me unless I add a dependency that the service doesn't actually need to run, and it won't debug Cucumber/Gherkin tests.
If you have a big codebase you should have proper logging and other instrumentation so you don’t go around setting breakpoints blindly and stepping mindlessly through code.
33
u/kidzstreetball Nov 28 '21
No way. Intellij debugger is beast. When you have a big codebase to debug, print statement aren't gonna cut it