Guide to PHP error reporting in 2019

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 set_error_handler(). 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_USER_ERROR (256): A user-generated version of the above fatal error. This is often generated through trigger_error().

  • E_USER_NOTICE (1024): A user-generated version of an informative event. This usually has no adverse effect on the app, much like a log.info().

The final category of note is the app lifecycle errors, usually with “core” or “compile” in the name:

  • EE_CORE_ERROR (16): Similar to the fatal errors above, this error can only occur when the PHP application starts up.

  • EE_COMPILE_WARNING (128): A nonfatal error that only happens when the PHP script fails to compile.

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 display_errors and display_startup_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:

PHP error monitoring in Raygun Crash Repoting

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.

It’s easy to plug in your own handlers and control the reporting and display of errors. This lets us plug in Raygun’s tool with little effort. So feel free to sign up for a Raygun trial and add it to your application in minutes.