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

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

echo "Hello"

This script is missing a semicolon, so PHP reports a parse error.

Logging errors to a file

<?php
error_reporting(E_ALL);
ini_set('log_errors', '1');
ini_set('error_log', __DIR__ . '/php-errors.log');

This writes errors to php-errors.log in the current directory.

Important note

For some parse errors, the script may fail before your ini_set() lines run. In that case, you should enable error display in your PHP configuration or server setup instead of relying only on code.

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

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

undefinedFunction();

Execution trace:

1. Error reporting is enabled.
2. PHP tries to call undefinedFunction().
3. The function does not exist.
4. PHP throws a fatal error.
5. The error message is shown instead of a blank page.

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.

4. Error logs from the web server

Sometimes PHP errors are not shown in the browser but are available in:

• Apache error log
• Nginx + PHP-FPM logs
• Container logs
• Hosting control panel logs

5. Framework support

Frameworks like Laravel and Symfony usually provide better formatted error pages in development and logging in production. Underneath, they still depend on PHP error reporting and exception handling.

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 try/catch, some errors still will not be handled the way you expect.

4. Ignoring log files

Sometimes browser output is blank because the server is configured not to display errors. The real message may already exist in a log file.

5. Hiding errors with the @ operator

Broken example:

<?php
$value = @file_get_contents('missing-file.txt');

Why it is a problem:

• @ suppresses the error message, making debugging harder.

How to avoid it:

• Remove @ while debugging and handle failures explicitly.

6. Not checking the correct PHP configuration

A server may have different configs for:

• CLI PHP
• Apache module PHP
• PHP-FPM

You might enable errors in one place and test in another.

Use:

<?php
phpinfo();

This helps confirm which configuration file is active.

display_errors vs log_errors

In-code settings vs server configuration

// 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

Typical production setup

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

If you still see a blank page

• Check the web server error log
• Check the PHP error log
• Confirm the correct php.ini is loaded
• Look for syntax errors before your debug lines run

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.

Is using echo for debugging enough?

It can help occasionally, but proper error reporting and logging are much more reliable and efficient.

• 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.