I hate PHP. PHP is the bunny in the road having a scratch, oblivious to impending, blood-streaked, gut-strewn death. It is the Saudi bar that serves everything except what you want. It is the mildly fragrant old man leaning too far through your passenger window giving you directions round the corner via the most perverse, circuitous route a human can devise.
In my job I work with PHP constantly. There’s no doubt that PHP is great for some projects: it’s easy to do simple stuff. But, my god, on substantial projects it’s a pain to work with compared to Python. All languages have their good points and their bad points, yes, blah, religious issue, you can write bad programs in any language, etc, but you can’t deny that Python has an elegance, a philosophy, that PHP has never had and never will.
PHP is an overflowing slop bucket of poorly named, arbitrarily parameterised, ill-considered functions encrusted with half-arsed OO bolt-ons and it doesn’t care two hoots about clarity, brevity or maintainability.
But all this is an aside, albeit a ranty, spit-flecked one, to the main point of this blog.
Ladies and gentlemen, let me introduce you to this PHP error:
Fatal error: Exception thrown without a stack frame in Unknown on line 0
You don’t need to be a PHP guru to realise that “Unknown on line 0” looks, smells and tastes like a PHP bug. There is no stack trace; no other assistance to help you track down the cause. That’s yer lot.
I’ve been seeing this error randomly on one particular cron job but, since I could find no resulting damage and my head was deeply entwined in some other code, I’ve left it alone until now. Today I investigated further. It turns out that PHP has an annoying limitation: it explodes with the entirely unhelpful fatal error above if there’s an uncaught exception within a destructor. It’s up to you to figure out which of your possibly large collection of objects is committing this particular mortal sin.
I discovered this via Google, which pointed me at PHP’s own bug tracker. The developer who reported the bug included everything a good developer should, including details of the stack trace he expected to see and the nonsense he received instead. There’s no doubt that this is a bug in PHP and the error message is entirely useless, no better than saying “bye!” and falling over.
The response:
Throwing exceptions in __desctruct() is not allowed.
Should be documented..
And so they treated it as a documentation problem, added a note to the doc, and closed the bug. See for yourself.
I cannot begin to describe how much this annoys me. Yes, document the problem. No, the problem has not been fixed. Adding a one-line note does not absolve PHP’s developers of any and all consequences, and PHP’s users are not helped in any way by this tiny documentation change. If you think they are, you are probably the type of person who mistakenly believes that engineers memorise every last wrinkle of every API they use.
But it gets worse. As in all bug trackers, especially those open to the public, there are duplicates. Duplicate reports of this particular bug get the response “Thank you for taking the time to write to us, but this is not a bug.” It’s not a bug because it’s mentioned in the documentation, of course! A magic wand is waved and all shall have presents!
This is just profoundly wrong. The only possible response in any professional development process is to reply “Thanks for the report, and sorry you hit this bug. As this has already been reported as bug XXX, we’re closing this report as a duplicate.” Bug XXX, of course, would be open and – I’d say – reasonably high priority since it can be so hard to debug.
I see similar things all the time in PHP’s bug tracker. In one case someone claims “That’s a gcc bug not a PHP bug” and promptly closes the bug, disregarding the fact that PHP is often built from source and its build process happily builds using this supposedly buggy gcc without warning the user that their code will break in undocumented ways. It’s really, really simple: just because there’s a bug in a downstream tool it doesn’t mean it’s not your problem: your users see a problem in your software, and see that you’re not helping – they don’t care about the downstream tool. “I’m sorry sir, I don’t see why we should fit a suspension system to our vehicles: the problem is with the roads.”
I’m picking on PHP but it’s by no means the only culprit, sadly. I’ve seen similar problems with ExtJS. Are there in fact any open source projects that get this right?
Avaragado's blog 