How to Handle PHP Fatal Errors (E_ERROR) in PHP

By the end of this page, you will understand why set_error_handler() cannot catch true PHP fatal errors, how fatal errors stop normal script execution, and how to detect them using register_shutdown_function() together with error_get_last(). You will also learn practical patterns for logging, alerting, and safely reacting to serious runtime failures in PHP.

In PHP, not all errors behave the same way.

set_error_handler() can handle many runtime errors, warnings, and notices, but true fatal errors like E_ERROR are different. A fatal error stops the script immediately. Because execution ends at once, PHP does not continue into your normal error handler.

This is why code like this does not catch a fatal error:

set_error_handler(function ($errno, $errstr, $errfile, $errline) {
    mail('admin@example.com', 'PHP Error', $errstr);
});

undefined_function(); // Fatal error

The custom error handler is skipped because PHP terminates execution.

The common workaround is to register a shutdown function using register_shutdown_function(). A shutdown function runs when the script is ending, including after many fatal errors. Inside it, you can inspect the last error using error_get_last().

This matters in real programming because production systems need a way to:

• log unexpected crashes
• alert developers or administrators
• show friendly messages to users
• record debugging details without exposing them publicly

In older PHP versions like PHP 5.2.3, this shutdown-based approach was the standard way to react to fatal errors that could not catch.

Think of PHP error handling like building security in a store:

• set_error_handler() is like a staff member handling small problems during business hours.
• A fatal error is like the power suddenly going out.
• When the power goes out, the staff member cannot continue normal work.
• register_shutdown_function() is like the emergency backup system that runs when the building is closing down.

So you do not really catch a fatal error in the usual sense. Instead, you run code at shutdown and inspect whether the script ended because of a fatal error.

The key tools are:

• set_error_handler() for non-fatal errors
• register_shutdown_function() for checking fatal errors at the end
• error_get_last() for reading the last occurred error

Basic fatal error detection

<?php
register_shutdown_function('handleFatalError');

function handleFatalError()
{
    $error = error_get_last();

    if ($error !== null && $error['type'] === E_ERROR) {
        mail(
            'admin@example.com',
            'Fatal PHP Error',
            "Message: {$error['message']}\nFile: {$error['file']}\nLine: {$error['line']}"
        );
    }
}

undefined_function();

What this does

• register_shutdown_function('handleFatalError') tells PHP to run handleFatalError() when the script ends.

Consider this example:

<?php
register_shutdown_function('handleShutdown');

echo "Start\n";
undefined_function();
echo "End\n";

function handleShutdown()
{
    $error = error_get_last();

    if ($error !== null && $error['type'] === E_ERROR) {
        echo "Shutdown detected fatal error: {$error['message']}\n";
    }
}

Execution trace

1. PHP registers the shutdown function handleShutdown.
2. echo "Start\n"; runs successfully.
3. PHP reaches undefined_function();.
4. Because the function does not exist, PHP raises a fatal E_ERROR.
5. Normal execution stops immediately.
6. echo "End\n"; never runs.
7. Before the script fully terminates, PHP runs the shutdown function.
8. Inside handleShutdown(), returns details about the fatal error.

Fatal error detection is useful in many real applications:

• Production monitoring: email or log when a script crashes unexpectedly.
• Background jobs: detect when a scheduled PHP task fails overnight.
• Legacy PHP systems: add minimal crash reporting without rewriting the whole app.
• Form handlers: record unexpected failures before the response ends.
• API endpoints: log crash details for debugging when requests fail.

Example: a cron job imports CSV files every night. If a missing function or unrecoverable error stops the job, a shutdown function can log the exact file and line so the issue is found quickly.

Example: an old PHP 5.2 application cannot use modern exception-based patterns everywhere. A shutdown handler can still provide a safety net for severe crashes.

In real projects, developers usually do not rely on email for every error because it can create too much noise. Instead, they combine several patterns.

Common patterns

• Central logging: send fatal error details to error_log() or a log file.
• Alerting for severe failures only: email only when the error type is fatal.
• Environment checks: show detailed output in development, but log only in production.
• Guard clauses: validate important values early to reduce fatal conditions.
• Fallback shutdown reporting: use shutdown handlers as a last-resort safety mechanism.

Typical production pattern

<?php
register_shutdown_function('shutdownMonitor');

function shutdownMonitor()
{
    $error = error_get_last();

    if ($error === null) {
        return;
    }

    $fatalTypes = array(E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR);

    if (!in_array($error['type'], $fatalTypes)) {
        return;
    }

    $message = sprintf(
        ,
        [],
        [],
        [],
        []
    );

    ();
}

1. Expecting set_error_handler() to catch E_ERROR

This is the most common misunderstanding.

<?php
set_error_handler('myHandler');

function myHandler($errno, $errstr)
{
    echo "Caught: $errstr";
}

undefined_function();

This will not catch the fatal error.

Avoid it by: using register_shutdown_function() for fatal shutdown detection.

2. Thinking shutdown handling can continue execution

A shutdown function does not recover the script.

<?php
register_shutdown_function('handleShutdown');
undefined_function();
echo "Still running";

echo "Still running"; never executes.

Avoid it by: treating shutdown handlers as reporting tools, not recovery tools.

vs shutdown function

// Non-fatal errors
set_error_handler('handleError');

// Fatal shutdown detection
register_shutdown_function('handleShutdown');

function handleError($errno, $errstr, $errfile, $errline)
{
    error_log("[$errno] $errstr in $errfile on line $errline");
}

function handleShutdown()
{
    $error = error_get_last();

    if ($error !== null && in_array($error['type'], array(E_ERROR, E_PARSE, E_CORE_ERROR, E_COMPILE_ERROR))) {
        error_log("Fatal: {$error['message']} in {$error['file']} on line {$error['line']}");
    }
}

Key rules

• set_error_handler() does not catch true fatal .

Can set_error_handler() catch fatal errors in PHP?

No. It can handle many non-fatal errors, but true fatal errors like E_ERROR terminate execution before the normal error handler can continue.

How do I handle fatal errors in PHP 5.2?

Use register_shutdown_function() and inspect error_get_last() when the script ends.

Can I recover from a fatal error and keep the script running?

No. A fatal error stops the script. A shutdown function only lets you inspect or report the failure before the process fully ends.

Should I use mail() for every PHP error?

Usually no. It is better to log most errors and reserve email alerts for serious or rare failures.

What does error_get_last() return?

It returns the last error as an array containing details such as type, message, file, and line, or null if no error occurred.

Can I detect parse errors this way?

In many cases, shutdown detection can help report parse-related fatal conditions, but the script itself cannot continue normally after them.

What is the safest production approach?

Use a shutdown function to log fatal errors, use set_error_handler() for non-fatal ones, and avoid showing raw error details to users.

• PHP error handling — the broader system of notices, warnings, and fatal errors.
• set_error_handler() — used for custom handling of non-fatal PHP errors.
• register_shutdown_function() — the main tool for shutdown-time fatal error inspection.
• error_get_last() — retrieves information about the last PHP error.
• error_log() — commonly used to record errors safely in production.
• Exceptions in PHP — useful for controlled application errors, but different from classic fatal engine errors.
• Defensive programming — helps reduce fatal conditions through validation and guard clauses.