This entry gets a little nerdy, and into the underlying depths and behaviour of CodeIgniter.  If you aren’t interested in the explanations, and just want to know what a good best-practice might be for application development with CodeIgniter, then just skip to the bottom paragraph now.  If however you are a glutton for convoluted writing and technical details, then read on!

Recently, I dealt with the idea of PHP error messages and logging in CodeIgniter.  Since CodeIgniter subverts PHP errors for its own purposes, I thought I’d write a bit about how it works.

Firstly, a quick summary of how PHP throws errors.  PHP has various levels of error reporting that range from “don’t report anything” to “everything, in explicit detail”.  What level of error you get when you run your scripts is controlled by how your server is configured - if those errors ever make it to the screen or not is controlled by a server setting called display_errors.

Many people (including the CodeIgniter manual) will encourage you to not show error messages to the end user for the sake of security; displaying the error message could provide insight into how the system is running, and therefore, how to compromise it.

The problem for a framework like CodeIgniter though, is that it will be implemented in all kinds of different server configurations and permissions.  Depending on who hosts a site, and how they’ve got stuff set up, a developer may, or may not, have access to the underlying server settings such as “display_errors” and the like.  So the underlying server settings are kind of an unknown.  So what CodeIgniter does to make it known is use the PHP function error_reporting on every page call, which effectively overrides the settings of display_error.

So now a developer has access to the error reporting of every page that is run, and thus, control of whether or not errors should be visible.  Even if you have access to the underlying server configuration, I’d still encourage users to continue with error_reporting, as it is more predictable and portable, across a wider base of servers.  error_reporting() can be found in the index.php file.

So punchline here, the display of errors is controlled by the error_reporting() level.

But just because you’re preventing errors from displaying doesn’t mean you don’t want to know what (if any) the errors where.  Here’s another place CodeIgniter helps out with its native error handling.  Every time a page is run, a log file is generated.  What (if anything) makes it into this log is entirely under developer control. 

When an error is encountered, we use set_error_handler to make this error available for logging if your logging threshold warrants it.  The logging threshold is available in “system/application/config/config.php”, and is $config[‘log_threshold’]. The comments are pretty self explanatory, but anything 1 or higher will capture your errors into the log files, which are available in “system/logs”.

So punchline here, the logging of errors is controlled by the log_threshold configuration.

If you wanted to log your errors, but not display them to screen, then you could set the error_reporting at “0” in the index.php, and your log threshold at 1 or more in the config.  This is what I do for nearly all my applications.