Error Reporting During Development

Error reporting controls which PHP problems are reported and where those reports go. During development, you want PHP to be loud. Notices, warnings, deprecations, and fatal errors are useful signals that something in the code is unclear, outdated, or broken.

The goal is not to hide messages until the page looks clean. The goal is to see problems early and fix the cause.

Development should report everything

For local development, use E_ALL so PHP reports every category of error it knows about.

<?php

declare(strict_types=1);

error_reporting(E_ALL);
ini_set('display_errors', '1');

error_reporting(E_ALL) chooses what PHP reports. display_errors controls whether those reports are shown in the output. In development, seeing the message is useful because it points directly to the file and line.

Production should not display errors

Production is different. Users should not see raw PHP warnings, paths, stack traces, environment details, or database information.

<?php

declare(strict_types=1);

error_reporting(E_ALL);
ini_set('display_errors', '0');
ini_set('log_errors', '1');

Production should still report and log problems. It should not display internal details to the user.

Error reporting is not error handling

Error reporting tells you that something happened. Error handling decides how the program responds.

This code avoids an undefined array key by checking the input before using it.

<?php

declare(strict_types=1);

$product = ['name' => 'Notebook'];

if (! array_key_exists('price', $product)) {
    echo 'Missing price';
    exit;
}

echo $product['price'];

// Prints:
// Missing price

The fix is not to suppress the warning. The fix is to handle the missing data deliberately.

Common messages beginners should recognise

An undefined array key usually means code expected a key that was not present.

<?php

declare(strict_types=1);

$product = ['name' => 'Notebook'];

$price = $product['price'] ?? 0;

echo $price;

// Prints:
// 0

The null coalescing operator is useful when a missing value has a safe default. If the key is required, validation is better than silently defaulting.

Warnings can reveal real bugs

A warning is often telling you that the program is making an unsafe assumption. For example, division by zero should be prevented before calculation.

<?php

declare(strict_types=1);

function averagePrice(int $total, int $count): int
{
    if ($count === 0) {
        throw new InvalidArgumentException('Count must be greater than zero.');
    }

    return intdiv($total, $count);
}

echo averagePrice(1000, 4);

// Prints:
// 250

The guard clause makes the failure rule explicit instead of letting the runtime fail later.

Deprecations are future work warnings

Deprecation messages mean the code still runs now, but the feature or behaviour is being phased out. Treat deprecations as maintenance work. They often become harder to fix after a PHP version upgrade is already underway.

In a team, deprecations may be handled gradually. The important habit is to record them, understand them, and avoid adding new ones.

Where settings live

Error reporting can be configured in several places:

• php.ini
• web server or PHP-FPM pool configuration
• framework environment files
• Docker images
• local bootstrap scripts
• test runner configuration

For small learning scripts, setting values in the script is acceptable. In real applications, environment-specific configuration is usually better because development and production need different display behaviour.

Do not use suppression as a fix

PHP has an error suppression operator, @, but beginners should be very cautious with it. Suppressing a message hides the signal without fixing the cause.

Prefer validation:

<?php

declare(strict_types=1);

function productName(array $product): string
{
    if (trim($product['name'] ?? '') === '') {
        throw new InvalidArgumentException('Product name is required.');
    }

    return trim($product['name']);
}

This code says what is required and fails clearly when the requirement is not met.

What to remember

In development, configure PHP so problems are visible. In production, log problems without showing internal details to users. When PHP reports a warning or notice, fix the assumption that caused it.

Before moving on, make sure you can explain the difference between error_reporting, display_errors, and log_errors, and fix a missing array key without suppressing the warning.