An IDE debugger lets you change the values of variables at run-time. An IDE debugger lets you see the value of variables you didn't know you wanted to see when execution began. An IDE debugger lets you conditionally break execution at any point in code, based on a condition, not a line number.
The debugger component of an IDE typically provides the programmer with the capability to view memory and see variables, run the program to the next breakpoint, execute just the next line of code, and, in some cases, change the value of variables or even change the contents of the line of code about to be executed.
Debugging itself is a very difficult process because of the involvement of humans. Another reason due to which it is considered as difficult because it consumes a large amount of time and resources too.
Some examples of some abilities that an IDE debugger will give you over trace messages in code:
In summary, print statements are (generally) static and you'll need to re-compile to get additional information if your original statements weren't detailed enough. The IDE removes this static barrier, giving you a dynamic toolkit at your fingertips.
When I first started coding, I couldn't understand what the big deal with debuggers was and I thought I could achieve anything with tracing (granted, that was on unix and the debugger was GDB). But once you learn how to properly use a graphical debugger, you don't want to go back to print statements.
An IDE debugger lets you change the values of variables at run-time.
An IDE debugger lets you see the value of variables you didn't know you wanted to see when execution began.
An IDE debugger lets you see the call stack and examine the state of the function passed weird values. (think this function is called from hundreds of places, you don't know where these weird values are coming from)
An IDE debugger lets you conditionally break execution at any point in code, based on a condition, not a line number.
An IDE debugger will let you examine the state of the program in the case of an unhandled exception instead of just crapping out.
Here's one thing that you definitely cannot debug with "print" statement, which is when a customer brings you memory dump and says "your program crashed, can you tell me why?"
I think debugging using print statements is a lost art, and very important for every developer to learn. Once you know how to do that, certain classes of bugs become much easier to debug that way than through an IDE. Programmers who know this technique also have a really good feel of what's useful information to put in a log message (not to mention you'll actually end up reading the log) for non-debugging purposes as well.
That said, you really should know how to use the step-through debugger, since for a different class of bugs it is WAY easier. I'll leave it up to the other excellent answers already posted to explain why :)
Off the top of my head:
As alternative to debug in IDE you can try great Google Chrome extension PHP Console with php library that allows to:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With