Logging and Debugging

Displaying error messages to the browser is a problem from many points of view. First, you're letting your visitors know that something in your code is broken, thus shaking their confidence in the solidity of your website. Second, you're exposing yourself to potential security vulnerabilities because some of the information outputted might be used to hack into your system. Third, you're preventing yourself from finding out what error occurred so that you can fix it.

A good solution to this problem consists of changing your php.ini setting so that the errors are not displayed to the screen, but stored in a log file. This is done by turning display_errors to off and log_errors to on, as well as setting a log file where the error messages are stored through the error_log option. You can open a shell and use tail –f to follow the PHP log.

If you want to go a step further, you could use the set_error_handler() function to define your own error handlers and log additional information that you might find useful when trying to troubleshoot the problem.

Naturally, you can also use the error-suppression operator @ to prevent PHP from displaying or logging the error. Although this is an easy way to solve the problem, it could lead to problems when using in production scenarios in which you do need to find out when an error occurs so that you can fix it.

Using Debuggers

Ultimately, not all bugs can be solved just by staring really hard at the code (although it often helps to). In some cases, you just need to "see" the program running to discover what's causing it not to perform properly. What you need is a debugger.

A lot of debuggers exist, starting with the ancient DBG (now integrated into NuSphere's PHPEd) and progressing to APD, XDebug and the debugger that's integrated into the Zend Studio IDE. Most debuggers have the capability to set breakpoints on specific lines in your code and watch points where you can watch the global scope of your PHP variables.

Using a debugger, you can step through each line of your application and see exactly how it flows. As such, you should definitely be familiar with one because some day you're definitely going to need one.