How to Show Useful Error Messages in PHP

By the end of this page, you will understand how PHP error reporting works, how to display errors during development, how to log them safely, and why a blank page usually means an error is being hidden rather than absent.

PHP can report many kinds of problems: syntax errors, warnings, notices, deprecated features, and fatal errors. If error display is turned off, a script may fail and show only a blank page, which is often called the white screen of death.

The key idea is that PHP has two separate error behaviors:

• Display errors: show errors directly in the browser or terminal
• Log errors: write errors to a file or server log

During development, you usually want to display and log errors. In production, you usually want to log errors but not display them, so users do not see internal details.

The most common tools are:

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

These tell PHP to report all errors and display them.

Why this matters:

• It helps you find syntax mistakes quickly
• It reveals failed function calls and undefined variables
• It makes debugging much faster than adding many echo statements
• It supports safer production setups through logging instead of screen output

A blank page usually does not mean nothing went wrong. It often means PHP encountered an error, but your configuration hid it.

Think of PHP errors like warning lights in a car.

• If the dashboard lights are enabled, you immediately see that something is wrong.
• If the lights are disabled, the car may still fail, but you get no clue why.

error_reporting() decides which warning lights are active.

display_errors decides whether those warning lights are shown to you on screen.

log_errors decides whether the issue is written into a maintenance record for later review.

So when you get a blank page, the engine may already be telling you something is wrong—you just are not seeing the dashboard.

To show useful errors in PHP during development, use this near the top of your script:

<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');

What each line does

• error_reporting(E_ALL); enables reporting for all PHP errors, warnings, and notices
• ini_set('display_errors', '1'); tells PHP to show errors in the output
• ini_set('display_startup_errors', '1'); shows errors that happen during PHP startup

Example: undefined variable

<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');

$total = $price + 10;
echo $total;

You would see an error because $price was never defined.

Example: syntax error

Consider this script:

<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');

$name = "Sam";
echo $nama;

Step by step

1. PHP reads error_reporting(E_ALL);

   • All error levels are enabled.

2. PHP reads ini_set('display_errors', '1');

   • Errors will be shown in the browser.

3. PHP assigns "Sam" to $name.

   • This works normally.

4. PHP reaches echo $nama;

   • $nama does not exist.
   • PHP raises a warning about an undefined variable.

5. Because error display is enabled, the warning appears on screen.

   • Without error display, you might only see missing output or a blank page.

Another example with a fatal error

Useful PHP error messages are important in many practical situations:

• Building forms: find undefined $_POST keys, validation mistakes, or type problems
• Working with databases: detect failed connections, bad SQL calls, or null values
• Calling APIs: catch invalid responses, missing fields, or timeout-related warnings
• File uploads: find permission errors, missing directories, or failed file moves
• Template rendering: spot missing variables in included PHP views
• CLI scripts: understand why scheduled jobs or maintenance scripts failed

Example in a form handler:

<?php
error_reporting(E_ALL);
ini_set('display_errors', '1');

$email = $_POST['email'];
echo "Email: " . $email;

If the form did not submit email, PHP can warn you immediately, which helps you fix the logic faster.

In real projects, developers usually combine error display, logging, validation, and structured debugging.

Common patterns

1. Development vs production configuration

Developers often use different settings depending on environment:

<?php
if ($_ENV['APP_ENV'] === 'development') {
    error_reporting(E_ALL);
    ini_set('display_errors', '1');
} else {
    error_reporting(E_ALL);
    ini_set('display_errors', '0');
    ini_set('log_errors', '1');
}

2. Logging instead of showing errors to users

In production, showing raw errors can expose file paths, SQL details, and internal code structure. Logging is safer.

3. Guard clauses and validation

Developers reduce errors by checking inputs early:

<?php
if (!isset($_POST['email'])) {
    exit('Email is required');
}

This avoids later warnings and makes the failure clearer.

Here are common beginner mistakes when trying to get useful PHP errors.

1. Enabling errors too late

Broken example:

<?php

echo "Start"

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

Why it fails:

• The syntax error happens before PHP can run the error settings.

How to avoid it:

• Enable error display in php.ini, .htaccess, virtual host config, or server config when needed.

2. Using display errors in production

Broken approach:

ini_set('display_errors', '1');

Why it is risky:

• Users may see sensitive paths, SQL messages, or application internals.

How to avoid it:

• Use display_errors=0 and log_errors=1 in production.

3. Assuming all problems are exceptions

In PHP, many issues are warnings or notices, not exceptions. If you only use , some errors still will not be handled the way you expect.

// Development settings
error_reporting(E_ALL);
ini_set('display_errors', '1');
ini_set('display_startup_errors', '1');

// Log errors
ini_set('log_errors', '1');
ini_set('error_log', __DIR__ . '/php-errors.log');

Key rules

• Use E_ALL to report everything useful
• Use display_errors=1 in development
• Use display_errors=0 in production
• Use log_errors=1 in production
• Parse errors may require php.ini or server-level config
• Avoid the @ operator when debugging

Useful places to check

• PHP script with ini_set()
• php.ini
• Apache or Nginx logs
• PHP-FPM logs
• Hosting dashboard error logs

Why does PHP show a blank page instead of an error?

Usually because an error occurred but display_errors is off, so the message is hidden.

What is the fastest way to show PHP errors during development?

Add the following near the top of your script:

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

Why do syntax errors sometimes still not show?

Because the script may fail before those lines execute. In that case, enable errors in php.ini or server configuration.

Should I enable display_errors on a live website?

No. It can expose sensitive internal details. Use logging instead.

Where can I find PHP errors if they are not shown in the browser?

Check PHP error logs, Apache or Nginx logs, PHP-FPM logs, or your hosting control panel logs.

What does E_ALL mean in PHP?

It tells PHP to report all available error levels, including warnings and notices.

Does try/catch replace PHP error reporting?

No. try/catch handles exceptions, but many PHP issues are warnings, notices, or fatal errors outside normal exception flow.

• PHP exceptions — Related because exceptions are another way PHP reports and handles failures.
• php.ini configuration — Related because many error settings are controlled globally there.
• Logging in PHP — Related because production systems usually log errors instead of displaying them.
• Debugging in PHP — Related because error reporting is one of the core debugging tools.
• PHP warnings and notices — Related because understanding error levels helps you interpret messages correctly.
• Web server logs — Related because Apache, Nginx, or PHP-FPM often contain hidden error details.
• PHP parse errors — Related because syntax mistakes are a common cause of blank pages.
• Environment configuration — Related because development and production should use different error settings.