PHP has been around for quite a while and has developed its own quirks and characteristics. It has also developed its own flavor of error reporting, which is fairly straightforward. In this post, we’ll show you how easy it is to add error monitoring for PHP.
What is a PHP error?
A PHP error is a data structure that represents something that went wrong in your application. PHP has some specific ways you can invoke errors. One easy way to simulate an error is with the die() function:
die("something bad happened!");
This will end the PHP program and report an error. When a program is ended, this is what we would call a fatal error. You’ll see later that we can control how exactly the error is handled, in case we need to invoke some cleanup logic or divert where the error reports. You can also simulate this with the trigger_error() function:
<?php
trigger_error("something happened"); //error level is E_USER_NOTICE
//You can control error level
trigger_error("something bad happened", E_USER_ERROR);
?>
This will trigger a nonfatal notice in the system by default. You can override the error level if you need a more severe error.
There are actually two forms of errors in PHP: standard run-of-the-mill errors, and exceptions.
Exceptions were introduced in PHP 5. They give you easier semantics like try, throw, and catch. It’s easy to throw an exception. This follows along with the great success statically typed languages, like C# and Java, have had with them.
throw new Exception("Yo, something exceptional happened);
Catching and throwing exceptions tend to be more streamlined than the more traditional PHP error handling. You can also have more localized error handling, as opposed to only handling errors globally via seterrorhandler(). You can surround specific logic with try/catch blocks that only care about specific exceptions:
<?php try {
doSystemLogic();
} catch (SystemException $e) {
echo 'Caught system exception ';
}
try {
doUserLogic();
} catch (Exception $e) {
echo 'Caught misc exception ';
}
?>
How to enable error reporting in PHP
Enabling error reporting in PHP is dead easy. You simply call a function in your script:
<?php
error_reporting(E_ALL);
//You can also report all errors by using -1
error_reporting(-1);
//If you are feeling old school
ini_set('error_reporting', E_ALL);
?>
This says “please report errors of all levels.” We’ll cover what levels are later, but consider it a category of error. So it’s essentially saying “report all categories of errors.” You can turn off error reporting by setting 0:<?php
error_reporting(0);
?>
The method parameter in error_reporting() is actually a bitmask. You can specify different combinations of error levels in it using this mask, as you can see:
<?php
error_reporting(E_ERROR | E_WARNING | E_PARSE);
?>
This says “report fatal errors, warnings, and parser errors.” You can simply delimit by “|” to add more errors. Sometimes you may want more advanced error reporting settings. You can leverage bitmask operators to report on a variety of criteria:
<?php
// Report all errors except E_NOTICE
error_reporting(E_ALL & ~E_NOTICE);
?>
As you can see, you have quite a bit of flexibility in determining what errors to report. That does beg the question: what types of errors and exceptions are there to report on?
How many error levels are available in PHP?
There are a whopping 16 error levels in PHP 5. These errors represent the category and sometimes severity of an error in PHP. There are a lot, but the numerous categories let you easily identify where to debug an error from its level alone. So, if you wanted to do something specific only for user errors, like input validation, you can define a condition handler for anything starting with E*USER. If you wanted to ensure you shut down a resource, you can do that by clueing into errors ending with *ERROR.
Errors in PHP are for the most part categorized by their severity (error warning, notice) and source (user, compiler, runtime).
I want to hone in on a few popular ones here.
First up, we have the general errors:
- E_ERROR (Value 1): This is the quintessential fatal error. If you see this bad boy, your app is done for. Restart and try again.
- E_WARNING (2): These are errors that don’t crash your app. Most errors seem to be at this level.
Next, we have user errors:
- E_ERROR (Value 1): This is the quintessential fatal error. If you see this bad boy, your app is done for. Restart and try again.
- E_WARNING (2): These are errors that don’t crash your app. Most errors seem to be at this level.
The final category of note is the app lifecycle errors, usually with “core” or “compile” in the name:
- E_ERROR (Value 1): This is the quintessential fatal error. If you see this bad boy, your app is done for. Restart and try again.
- E_WARNING (2): These are errors that don’t crash your app. Most errors seem to be at this level.
There are a few other errors. You can find the entire list of them here.
PHP display errors
In PHP, you can decide whether or not to display errors. This is different from reporting them. Reporting them will ensure the errors are not swallowed. But displaying them will show them to the user. You can turn it on with the displayerrors and displaystartup_errors directive:
<?php
ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);
?>
Turning these on will ensure they show up in the body of the web response to the user. It’s usually a best practice to turn these off in nondevelopment environments. The integer method parameter is also a bitmask, like in error_reporting(). The same rules and options for that parameter also apply here.
What is a PHP warning?
You’ll note above that one of the error levels is E_WARNING. You may also have noted that many of the error levels have warning versions. I want to dig into this a bit. The main difference between a warning and an error in PHP is whether or not it ends the application. In PHP, most errors don’t actually stop the script from executing.
Here’s an example:
<?php
$x = 1;
trigger_error("user warning!", E_USER_WARNING);
$x = 3;
echo "$x is ${$x}";
?>
You will still see $x is 3 despite triggering the warning. This can be useful if you want to collect a list of validation errors. I personally prefer to use exceptions these days, but your mileage may vary.
How Crash Reporting helps
PHP makes it easy to set up external error reporting tools, like those offered by Raygun. It provides a few different hooks into its runtime to handle errors and send them over the wire. See this example, torn from Raygun’s PHP page:
namespace
{
// paste your 'requires' statement
$client = new \Raygun4php\RaygunClient("apikey for your application");
function error_handler($errno, $errstr, $errfile, $errline ) {
global $client;
$client->SendError($errno, $errstr, $errfile, $errline);
}
function exception_handler($exception)
{
global $client;
$client->SendException($exception);
}
set_exception_handler('exception_handler');
set_error_handler("error_handler");
}
First, we declare the client, using an API key for security:
$client = new \Raygun4php\RaygunClient("apikey for your application");
Then we create a couple of functions that handle our errors and exceptions:
function error_handler($errno, $errstr, $errfile, $errline ) {
global $client;
$client->SendError($errno, $errstr, $errfile, $errline);
}
function exception_handler($exception)
{
global $client;
$client->SendException($exception);
}
Note we call the SendError() function, passing in a few relevant details about the error data structure. This will make a remote call to Raygun.
Finally, we hook these into PHP’s runtime by globally handling both traditional errors and the newer exceptions:
set_exception_handler('exception_handler');
set_error_handler("error_handler");
And that’s it. With this all in place, we can get beautifully formatted error reporting that can look like this:
Wrapping up PHP error reporting
As you can see, PHP error reporting is straightforward. You can trigger exceptions through special functions. You can also trigger exceptions, like in other typed languages.
#php
