LinLog

You ever have one of those annoying programming moments where you know something isn't working, but for the life of you, you can't figure out why? And then, after spending way too much time on it, it turns out to be a stupid little typo or something like that? And then you're not sure whether to curse yourself for being so stupid or the compiler/interpreter/whatever for not providing a half-way meaningful error message?

I had one of those the other day. I was writing some PHP code to update a MySQL database using the object-oriented interface to the MySQL Improved extension. My problem was that my call to the $connection->prepare($sql) method was failing for no apparent reason.

For those who aren't PHP programmers, PHP 5 introduced MySQL Improved, or mysqli, a new extension for accessing MySQL databases. This includes support for prepared SQL statements. That basically means that you can parameterize your SQL, compiling the SQL and then injecting values from your code into the syntax and type-checked statement. This is a huge improvement over the old, hideously insecure method of just building up a string in code and passing it wholesale to the database.

Anyway, my problem was with the method that prepares an SQL statement. In particular, its return value - it returns a prepared statement object on success, false on failure. In my case, the method was returning false, which meant that MySQL couldn't prepare my statement because...well, it just couldn't. No exception, no message saying what was wrong with the query, just a failure code.

My question is: why? Wouldn't it make more sense to at least raise a warning to give you some idea of why the prepare failed? Or at least set the last error message for the connection? MySQL presumably has some idea why the prepare failed. Why can't the mysqli extension pass that on? After all, machines are good at finding typos. Much better than the developers who put them there in the first place.