February 8, 2008 at 2:55PM Things I hate: PHP errors
While I’m more comfortable writing code in it than some other languages, there’s one thing about PHP that makes me want to beat the developers around the head: how it deals with errors, but specifically how it doesn’t give 500 Internal Server Error status codes when an error occurs and it has a chance to do so.
Take this simple piece of code:
<?php bug();
This should guarantee us an error because there’s no bug() function defined. Let’s save that to a file:
Now, let’s view it in Firefox:
A fatal error, just as we expected. You’ll notice that the error isn’t the usual one. That’s because I use the excellent xdebug, though this has no bearing on PHP’s behaviour in this regard.
Let’s do a HEAD request:
200 OK?
A fatal error occurs that PHP could trap before any output gets sent and I get a 200 OK?! That’s just wrong, and here’s why:
Let’s say you’re writing a machine-readable service of some kind. Clients of this service rely on the server they’re talking to giving back reliable status code to tell if their request has succeeded.
Now, say said service has a bug in it such as the one demonstrated above. How exactly are clients meant to tell if their request has succeeded or not?
PHP is a pain for writing machine-readable services in. php -l won’t catch these kinds of bugs and Providence knows it’s easy enough for these kinds of things to get through in the form of spelling errors. It ought to be at least possible to get PHP to send 500 status codes in the case of error even if that’s not the default setting. Fail fast is a good thing in a machine-readable system.
No comments.