Insane library design

My current project at work is to integrate a web application that runs one aspect of our site with the rest of the site. Part of this involves converting the database code from a custom DB abstraction library to use the standard PHP Data Objects (PDO) library that comes with PHP 5.1. I had never used it before, but it turns out PDO isn't a bad library. It has an object-oriented API, supports multiple databases, "prepared" (i.e. DBMS parametrized) queries, transactions, and so forth. Pretty much the basic features you need in a database abstraction layer. The only problem is that the error handling API is somewhere between "weird" and "completely frickin' insane."

You see, PDO has "configurable" error handling. That is, when a method reaches an error condition, it will either return an error code or throw an exception. Which one it does is determined by an attribute setting on the PDO connection object. (Technically, it may actually return the error code and throw an exception, but the return value is irrelevant once an exception is thrown, so it doesn't really make any difference.)

Let me repeat that, in case you missed it: PDO will either throw an exception or return an error code, depending on a setting of the PDO connection object. So it's possible to change one single constant and break error handling for an entire script.

Upon learning this, my initial reaction was: "That's the stupidest thing I've ever heard in my life!" I mean, honestly, who ever heard of configurable error handling? As if programmers don't have enough to worry about with database code, now we have to pick an error handling mode as well?!? And the worst part is that, when you read the error handling documentation, the default mode not only doesn't throw an exception, it doesn't even print a warning. It just leaves you to see the bad return value and manually inspect the error code on the object. You have to manually set it to turn on warning messages. Why?!? Isn't that why we have the error_reporting variable in php.ini? What the heck were they thinking?!?

What really kills me is that exceptions are optional, but object-oriented programming is mandatory. Unlike, say, the MySQL extension, PDO does not have a procedural version of the API, just the object-oriented one. And yet exceptions, which I think I can safely say are the object-oriented way of doing error handling, aren't even used by default. Shouldn't that be the only way of dealing with errors? Why is it better to make them optional? What's the rationale behind that?

So far, the only rationale I can think of is that the PHP community has what seems to be a disproportionate number of morons in it. That may be a little harsh, but it seems to me like there are a lot of third-rate PHP programmers and that the people who run the PHP project tend to go a little too far to cater to them. I can only assume that somebody thought that exceptions might be too hard for some PHP users, so they figured it would be better to use error codes by default. Kind of like how they figured securing your server was too hard, so they added the fake band-aid of safe_mode. Or how they figured a simple function call or array look-up was too hard, so the invented register_globals. Or how they figured that cleaning form input was too hard, so the invented "magic quotes."

PHP isn't a bad language, and I do enjoy working with it, but it has gone through a long list of really bone-headed design decisions. In some ways, it seems like it's succeeded in spite of itself. I guess this is really just evolution in action. Take a simple template engine, let it mutate into a full-blown programming language, and this is what you get: a platypus. Lots of endearing features and lots of brain-dead features, but it's still alive and still evolving.

You can reply to this entry by leaving a comment below. You can send TrackBack pings to this URL. This entry accepts Pingbacks from other blogs. You can follow comments on this entry by subscribing to the RSS feed.

Add your comments #

A comment body is required. No HTML code allowed. URLs starting with http:// or ftp:// will be automatically converted to hyperlinks.