Why PHP sucks #1

Welcome to my series of posts of why PHP is the worst language I've ever had to work with. Today's topic is error handling. Or perhaps PHP's lack of it. One of PHP's philosophies seems to be that the programmer should not be troubled by any nasty errors. It's better to attempt to do something even if that is wrong. Failing fast with a clean error message and a stack trace is not one of PHP's virtues.

PHP seems to (I'm just guessing here) have only had errors (with different codes for warnings, notices etc.) before. Now it also has exceptions. This is pretty annoying because you end up having to write your error logging code. This involves setting up your own custom error handler which rethrows the errors as exceptions. Then you can add your own custom exception handler which can obtain a stacktrace from the exception and print it out inside <pre> tags so that you can make some sense of it.

Then you figure out that PHP treats "fatal errors" differently. It bypasses your error_handler and just shuts down your application instead. Then you figure out that you can register a shutdown function and try to output a stacktrace manually from there. Unfortunately by the time this function is called PHP has already torn down most of the stuff you were using and the only thing in your stacktrace is gonna be your own shutdown function.

So you end up installing the xdebug extension and by enabling it you can finally get some output when your program. Except it's a big mess of lines where you end up just having to go through all the mentioned lines to see if you can figure out what's causing your problems. Then after a while you notice that you can echo a single opening <pre> tag at the beginning of your script while debugging your errors and suddenly all the output from xdebug is quite readable. But the fact that you have to go through all of this crap shows why PHP sucks.