Most PHP programmers seem to have given up and resorted to using echo for debugging.
Most PHP programmers seem to have given up and resorted to using echo for debugging.
It's also something you only have to do once, on your development box. So I don't really consider that a hurdle.
From there, some libraries like ezpublish will cause all sort of problems with xdebug depending on where you put the breakpoint (it might be due to the number of recursive call or stack depth), and you'd really want to enable or disable debugging case by case, from your IDE ideally.
Then debugging on a non dev server means installing a new package, configuring it and disable it afterwards just in case it has ill adverse effects.
Then some eclipse pdt versions were stuck when using xdebug on some configs.
Overall it works, but in practice, there's not enough cases IMO where step by step debugging is valuable enough to bother dealing with the not so exceptional weird things.
Which IDE do you use? Granted, most of my issues come from the IDE vendor's browser extension, which only triggers debugging when there's an 'R' in the month... which is highly frustrating.
The PHP experience is absolutely horrible compared to those of Java, Python, the .NET languages, and even to those of C, C++ and Objective-C.
Take Java, for example. Debugging works seamlessly in pretty much every major Java IDE, including the free ones, on pretty much every platform used for Java development. This has been the case for a decade now, if not longer. It takes basically no effort to start debugging Java code.
The .NET experience is even better, although more limited in terms of tooling. Debugging is stupidly simple and very efficient when using C# and Visual Studio. Again, it has been like this for many years now.
PHP needs to get its act together so that debugging is at least as simple as it is when using those other languages and runtimes. Anything less is just plain unacceptable today.
While installing XDebug may be no rocket-science, I've encountered too many situations that it just didn't work reliably, causing developers to revert to nasty var_dumps() for debugging.
• break at the first line in a script (very annoying when you have to debug something very deep)
• generate tracing logs (horrible to read but the best debugger replacement I had at the time)
• generate profiling logs (very helpful)
I never managed to get arbitrary breakpoints to work so I basically resorted to either traces or var_dump.