What’s the most common pattern for error handling you see in beginner’s PHP code? – That’s right,
do_X() or die('do_X failed);.
That’s nice and all, as at least you have some sort of error handling, but I think this way of handling errors must go. There is no place for it in modern PHP code – it’s the worst way to handle errors, not much better than not handling them at all.
So you are a newbie and want to learn how to do MySQL in PHP.
Okay, let’s do a google search: PHP MySQL tutorial
I’ll let you guess how many of the first 10 use “or die()” to catch failing queries.
All ten of them use “or die”! (and some even use the evil error eating @ operator)
So is it any wonder why it is so common?
If you’re a beginner, I’m not blaming you – how could you know of a better way if everything you can find talks about the bad way to do it?
How hard can it be to do error handling properly?
Never use die()
So why is
die() so bad?
For starters, it may be a decent approach. However, when the size of the codebase grows, it becomes more and more difficult to locate problems.
If your code dies, you won’t know the line. You won’t know the function, and not the file. You won’t be able to graciously handle the error either – The application will just stop right there, right then.
There are two other approaches that are better:
trigger_error is, in a way, the next step from
die(). Despite being the obvious next step, it’s still a much better approach.
- You’ll get better output: Not only will it show you the line number, it will tell you the filename too, so you know where to look. Even better, if you have Xdebug, you’ll get stack traces and other useful information.
- You will actually get output in the error log from this one.
- You can “catch” errors triggered by code using set_error_handler. This will allow you to maybe automatically display a nice “oops something went wrong” type of page or other such stuff
And perhaps also good is that you can use trigger_error in a very similar fashion as die:
do_X() or trigger_error('I have a boo boo', E_USER_ERROR);
This makes it very easy to make the jump to better error handling, and it can even be done with relative ease with an automatic search and replace.
Exceptions are in my opinion the way to handle errors.
- Exceptions are flexible: You can have use the standard exceptions or create custom ones to better describe the error.
- They can convey extra information: A custom exception class can, for example, include additional fields – it is an object afterall
- Using a try-catch block, you can easily handle exceptions on a case-by-case basis, making it easy to choose how to recover from specific exceptions.
Of course, the benefits mentioned for trigger_error also apply: Uncaught exceptions will provide good output (and better with Xdebug) and will cause output in the error log.
The only downside of using exceptions is that it’ll make your code a little more verbose. Except I lied when I said it’s a downside – more verbose code can be a good thing too.
or die() to handle errors.
Using either of the approaches mentioned here is much, much better. You’ll get output that makes it much easier to debug your code, the error log will actually become useful and you can handle your error cases much better in code, so that the application will not crap on the user.
You have no reason to use die() when encountering an error.
ps: Never make your error message say “I have a boo boo” 😉