Why (some) Open Source projects suck, part 94

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?


1 Comment

Filed under Random

One response to “Why (some) Open Source projects suck, part 94

  1. Roger

    Well mine is different and gets it right – APSW :-)

    It is import to separate the language from the library. Guido has impeccable taste for Python the language. PHP the language is somewhat ok for small scale stuff (like the original intended Personal Home Pages) but truly sucks at scale. And remind me why 3+”four” is valid.

    The Python standard library is mismatch of naming conventions, error handling, bizarre documentation etc. PHP’s library has really good documentation and all else is rather arbitrary and hence crap. They didn’t think to provide namespaces early on and reap the consequences. Do they even know what a Unicode string is yet?

    Lest you think Python is somehow perfect in this category I have several times had to use a C level debugger to work out what the heck is going on. These level of problems are far less likely to occur but when they do they are just as difficult to diagnose. (BTW the Python C api is just as tasteful as Python the language.) I only discovered many of these issues because of my need for 100% test coverage – your mileage will vary. An example I discovered yesterday in the standard library – try calling shlex.split with a Unicode string.

    But I’ll give you the biggest idiocy in Python in my opinion. If you define a __del__ method then Python makes no claim that it will ever be called. In fact in many cases there are explicit statements that adding a __del__ method means it won’t be called. In summary if it is important that an object is cleaned up and you define a method for that cleanup then it is unlikely Python will call the method. (See also catch-22.)

    This is also a useful reference to open source bug fixing:


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s