← Back to glossary

Error Reporting & Display

php PHP 4.0+ Beginner

debt(d7/e3/b5/t7)

d7 Detectability Operational debt — how invisible misuse is to your safety net

Closest to 'only careful code review or runtime testing' (d7). The term's detection_hints.tools field is not specified. Misconfigured error_reporting or display_errors settings produce no compile-time or linter feedback — the misconfiguration is silent until a developer notices missing error output in development or accidentally exposed stack traces in production. A code review or environment audit is the primary discovery mechanism; no standard default tooling catches it automatically.

e3 Effort Remediation debt — work required to fix once spotted

Closest to 'simple parameterised fix (replace pattern with safer alternative)' (e3). The quick_fix shows a small set of ini_set() and error_reporting() calls — two to three lines per environment. While the fix itself is trivial, it may need to be applied in multiple places (php.ini, .htaccess, bootstrap files, environment configs) making it slightly more than a single-line patch but well within one component.

b5 Burden Structural debt — long-term weight of choosing wrong

Closest to 'persistent productivity tax' (b5). The choice applies to both web and CLI contexts across all PHP versions from 4.0 onward. Misconfigured settings persistently slow debugging (display_errors off in dev) or introduce ongoing security exposure (display_errors on in prod). It affects every developer touching the codebase and every environment, but it doesn't architecturally reshape the system — it's a cross-cutting configuration tax rather than a structural constraint.

t7 Trap Cognitive debt — how counter-intuitive correct behaviour is

Closest to 'serious trap (contradicts how a similar concept works elsewhere)' (t7). The misconception field captures the core trap precisely: developers believe E_ALL and E_NOTICE are noise that breaks working code, when in fact they reveal real latent bugs. Additionally, the @ suppression operator appears to fix errors but silently allows incorrect behaviour to continue. The dual-environment trap (display_errors on in dev, off in prod) also catches many developers. These are non-obvious, widely held wrong beliefs about the concept's correct usage.

About DEBT scoring → scored by claude-sonnet-4-6 · 2026-05-07 · reviewed by human

Also Known As

error_reporting display_errors E_ALL E_NOTICE E_WARNING error suppression @ operator

TL;DR

PHP's error_reporting level and display_errors directive control which errors are shown and where — development needs E_ALL with display on; production needs E_ALL with display off and logging on.

Explanation

PHP has two distinct error controls: error_reporting sets which error types PHP generates (E_ALL includes all errors, warnings, notices, and deprecations); display_errors controls whether errors are output to the browser or CLI. The correct configuration differs by environment: Development — error_reporting(E_ALL), display_errors=On, display_startup_errors=On (see all errors immediately). Production — error_reporting(E_ALL), display_errors=Off, log_errors=On (log everything, show nothing to users). The E_ALL level includes E_NOTICE (undefined variables, array access), E_DEPRECATED (functions removed in future PHP versions), E_STRICT (code that may not be forward compatible), and E_WARNING. Setting error_reporting to E_ALL in development and fixing all notices prevents surprises when PHP version upgrades promote notices to errors. The @ error suppression operator silences individual expressions — a code smell that hides problems rather than fixing them.

Common Misconception

✗ Setting error_reporting to E_ALL in development will break working code with unnecessary noise. E_NOTICE and E_DEPRECATED are not noise — they are warnings about real problems. An undefined variable notice means your code is reading from a variable that may not always be set; that is a real bug waiting for the right conditions. E_DEPRECATED warnings about removed functions are advance warning of breaking changes on the next PHP upgrade. Fixing all E_ALL warnings in development prevents production surprises.

Why It Matters

The single most common PHP debugging mistake is working with display_errors=Off in development or error_reporting set too low — errors happen silently, the developer adds debugging code hunting symptoms rather than seeing the cause immediately. Conversely, display_errors=On in production is a security issue that exposes file paths, database connection strings, and stack traces. Getting these two settings correct for each environment takes two minutes and saves hours of debugging time.

Common Mistakes

Using error_reporting(0) or @ suppression to hide errors instead of fixing them — suppressed errors still occur and cause incorrect behaviour.
Setting display_errors=Off in development — makes debugging significantly harder; always show errors in development.
Not setting display_errors=Off in production — raw PHP errors expose sensitive information to users and attackers.
Checking for E_ALL without including custom error handlers — set_error_handler() captures errors that PHP would normally display; use it to log and handle errors programmatically.

Code Examples

✗ Vulnerable

// Suppressing instead of fixing
$result = @file_get_contents($url); // hides errors
if (!$result) { /* why did this fail? no idea */ }

// Wrong production config
display_errors = On  ; php.ini — shows errors to users
error_reporting = E_ERROR ; misses warnings and notices

✓ Fixed

// Development: show everything
if (getenv('APP_ENV') === 'development') {
    error_reporting(E_ALL);
    ini_set('display_errors', '1');
    ini_set('display_startup_errors', '1');
}

// Production: log everything, show nothing
if (getenv('APP_ENV') === 'production') {
    error_reporting(E_ALL);
    ini_set('display_errors', '0');
    ini_set('log_errors', '1');
    ini_set('error_log', '/var/log/php/app-errors.log');
}

// Fix instead of suppress
try {
    $result = file_get_contents($url);
    if ($result === false) throw new RuntimeException('Failed to fetch: ' . $url);
} catch (RuntimeException $e) {
    $this->logger->error($e->getMessage());
}

References

↗ https://www.php.net/manual/en/function.error-reporting.php