Error Handling

Introduction

Things go wrong in every program: a file might be missing, a variable might be undefined, or a function might be called with the wrong number of arguments. Long before modern exception handling existed, PHP already had a system for reporting these problems — its traditional error levels.

Understanding this older error system still matters, because PHP itself, and many libraries, continue to raise notices, warnings, and fatal errors this way. This lesson covers what those error levels mean, how to control what gets displayed, and how PHP has evolved to favor exceptions for problems your code can actually recover from.

PHP Error Levels

PHP classifies problems into different severity levels. Not every problem stops your script — some are just warnings that something looks off, while others are fatal and halt execution immediately.

<?php
echo $undefinedVariable;
echo "This line still runs.";

Warning: Undefined variable $undefinedVariable in notice-example.php on line 2
This line still runs.

Notice that the script kept running after the warning — this is a key difference from fatal errors, which stop execution on the spot.

<?php
echo "Before the call.\n";
undefinedFunction();
echo "This line never runs.";

Before the call.
Fatal error: Uncaught Error: Call to undefined function undefinedFunction() in fatal-example.php:3

Controlling Error Display

PHP gives you fine-grained control over which error levels get reported, and whether they are shown on the page at all. The error_reporting() function sets which levels are tracked, while the display_errors setting (in php.ini or set at runtime) controls whether they are printed to the output.

<?php
// Report all error types
error_reporting(E_ALL);

// Show errors directly in the page output
ini_set("display_errors", 1);

echo $stillUndefined;

Warning: Undefined variable $stillUndefined in error-reporting.php on line 7

You can also silence specific levels rather than all of them. For example, reporting everything except notices and deprecation warnings is common in older codebases still transitioning to stricter standards.

<?php
// Report everything except notices and deprecated warnings
error_reporting(E_ALL & ~E_NOTICE & ~E_DEPRECATED);

Development vs Production Settings

Showing detailed errors is helpful while building an application, but dangerous once it is live — error messages can reveal file paths, database structure, or other details useful to attackers. Because of this, development and production servers should be configured very differently.

<?php
// Typical production-safe configuration
error_reporting(E_ALL);
ini_set("display_errors", 0);
ini_set("log_errors", 1);
ini_set("error_log", "/var/log/php/app-errors.log");

Custom Error Handlers

Instead of relying on PHP's default error output, you can register your own function to handle errors using set_error_handler(). This is useful for logging errors in a custom format or sending alerts when something goes wrong.

<?php
function myErrorHandler($errno, $errstr, $errfile, $errline) {
    echo "Custom handler caught: [$errno] $errstr in $errfile on line $errline";
}

set_error_handler("myErrorHandler");

echo $undefinedAgain;

Custom handler caught: [2] Undefined variable $undefinedAgain in custom-handler.php on line 8

A custom handler receives the error level, message, file, and line number, giving you full control over what happens next — logging it, formatting it nicely, or even converting it into an exception.

The Trouble with @

PHP lets you prefix any expression with the @ operator to suppress errors it produces. While tempting, this is widely considered bad practice.

<?php
$value = @$array["missingKey"]; // no warning shown, even though the key does not exist
var_dump($value);

NULL

Errors vs Exceptions

This traditional error system has been part of PHP since its early days, but modern PHP increasingly favors exceptions for problems that your code can anticipate and recover from — like a failed file open, invalid user input, or a database connection failure.

Common Mistakes

Best Practices

Frequently Asked Questions

Key Takeaways

Summary

PHP's traditional error system — notices, warnings, and fatal errors — has existed since the language's earliest days, and understanding it helps you diagnose problems and configure your servers correctly, especially the crucial difference between development and production settings.

Next, you will learn about exception handling, the modern, more structured way PHP lets you catch and respond to problems your code can anticipate and recover from.