What a ridiculous title. But it’s a clever play on words, because I’m damn clever.

Writing code is one thing. But writing bad code, that’s an entirely different cake. And not the good cake, either. Writing bad PHP is like having that third piece of cake; it’s so easy to do, yet so easy to avoid, and oh so painful later on. In fact, you’ll probably regret it. I know I always do (on both accounts).

The following is a great way to debug your scripts:

mysql_connect('stop', 'eating', 'cake')
or die ( "Error: " . mysql_error() );

But there are several flaws in this. That’s why it’s for debugging. Not production level code.

• It violates one of the cardinal rules of usability: Graceful errors. Do you think your users want to see some garbled error puked at them? Of course not. They should be reassured that an administrator, like for instance, you, has been informed of the error, and the situation shall be resolved promptly. The situation, is under control. The results of a mysql_error() don’t benefit anyone other than you. And that’s a whole lot of no one.
• It reveals information about your server that is potentially a security risk. Often times these errors throw back table names, database names, database usernames, and your full server path. Why would you want people knowing this? If you did, you’d just publish this information publicly, on your MySpace page. But you don’t. So why should you let your errors get out of control? You need to leash them, like children.

taming your MySQL errors

There are several ways to go about this. For one, instead of calling mysql_error(), you can call a custom function. That function then makes a decision about either outputting the entire mysql_error() text, or a short user-friendly error. The function would know which to do, as an example, based on a constant you define in a global config file. This is similar to how phpBB handles their errors; in the admin panel you can elect to output either user-friendly errors, or the god-awful PHP errors in their entirety. Enable full errors while you’re still working on the script, and disable them once you’re at production level.

but that’s not enough

Most of the time, PHP likes to throw errors at you anyways. If you have a connection error, the code below will still display an ugly unfriendly line:

mysql_connect('stop', 'eating', 'cake') or die ( "Error: " . foo() );

The reason for this is because if un-dealt with, mysql_connect() itself will generate a PHP warning and send it to the browser. These warnings can however be suppressed with the @ symbol. For example:

@mysql_connect('stop', 'eating', 'cake') or die ( "Error: " . foo() ); 

With the above line, you now completely control what the user sees upon a connection error (since our databases never go down, right?). The @ symbol will ensure that no errors or warnings ever make it to the browser, and thus your users always think the situation is under control. Even though it probably isn’t.

and now you know

So please, for the love of God, control your errors. Make them nice, and pretty. If not for your users, then for the security factors.