Error Suppression Without the @ Operator: Clean Alternatives in PHP

1. Why the @ operator is an antipattern

The @ operator in front of a function call looks harmless, but it is not. It suppresses every error message PHP would generate at that exact point, regardless of which specific error occurs. Writing @fopen($path, 'r') to silently handle a missing file also silently suppresses every other possible cause: wrong file permissions, an exhausted file handle quota, a typo in the path from a broken variable, or access blocked by open_basedir.

The real problem is the lack of differentiation. Clean error handling distinguishes between the expected case, such as a missing file, and an unexpected case, such as a permissions problem in production. The @ operator treats both identically: it simply returns false or null and leaves the caller in the dark about why. In large codebases this regularly leads to hours of debugging, because the actual symptom surfaces somewhere completely different in the code.

2. What the @ operator technically does

Technically, the @ operator temporarily sets the internal error_reporting level to zero while the following expression is evaluated, then restores it afterward. An error triggered by the suppressed statement is still reported to an active error handler, but only if that handler is explicitly configured to run even at an error_reporting level of zero, which the default handler is not. In practice this means the error does not vanish from PHP's internal state, but it almost never ends up in a log or in error output.

Since PHP 8.0, the @ operator at least no longer swallows fatal errors, an earlier and particularly nasty pitfall that has since been closed. Warnings, notices, and deprecation messages remain invisible, though. That is the core of the problem, because modern PHP versions increasingly use warnings for cases that used to fail silently, such as invalid array access or type coercions, and those warnings are often valuable hints toward real bugs.

3. Example: @fopen and its silent follow-up errors

A classic example is reading a configuration file. If @fopen fails, the function returns false. If that return value is passed unchecked into fread, without strict_types this only produces further warnings, and with strict_types it produces an outright TypeError, but both happen at a point that has nothing to do with the actual cause anymore. The original reason the file could not be opened is already lost by that time.

It gets particularly tricky when production runs on a different filesystem than development. A permissions error that never shows up locally, because the developer works as the file owner, can be triggered live by missing read permissions for the web server user. Without logging, that difference stays invisible until a customer reports a blank page and the team starts sprinkling debug output through the whole application.

<?php

declare(strict_types=1);

// Antipattern: the actual cause of the error is completely lost
function loadConfigUnsafe(string $path): array
{
    $handle = @fopen($path, 'r');
    $content = @fread($handle, filesize($path));
    fclose($handle);

    return json_decode($content, true) ?? [];
}

4. Alternative 1: Check state before calling

The simplest and often sufficient alternative is an explicit upfront check with is_readable, file_exists, or is_writable. These functions return a clear boolean even though the actual operation could still fail afterward, for example due to a concurrent filesystem change. The decisive advantage is that a specific, meaningful error message can be raised right here, instead of an anonymous false value further down the call chain.

It is important not to mistake this check for a complete replacement of error handling, but rather to treat it as a first filter for the most common, expected cases. Between the check and the actual operation there is always a small window in which the state can change, a so called time-of-check-to-time-of-use problem. That is why the actual call still needs to be able to react to failure, just in a controlled way with context, instead of a silently swallowed error.

5. Alternative 2: set_error_handler for legacy functions

Many built-in PHP functions predate exceptions and still report errors exclusively through warnings instead of throwing. For exactly this case set_error_handler is the right tool: the registered handler catches the warning and converts it into a real ErrorException, which can then be handled with an ordinary try/catch. This creates a unified error path, regardless of whether a function throws natively or merely emits a warning.

The handler should be registered as narrowly as possible, right around the actual call, and removed immediately afterward with restore_error_handler, so it does not accidentally catch errors from completely unrelated code. This pattern combines the precision of a targeted try/catch block with the ability to cleanly integrate older, non exception based APIs into modern error handling.

<?php

declare(strict_types=1);

/**
 * Converts warnings raised inside the callable into an ErrorException.
 *
 * @template T
 * @param callable(): T $operation
 * @return T
 * @throws ErrorException
 */
function withErrorsAsExceptions(callable $operation): mixed
{
    set_error_handler(static function (
        int $severity,
        string $message,
        string $file,
        int $line
    ): bool {
        throw new ErrorException($message, 0, $severity, $file, $line);
    });

    try {
        return $operation();
    } finally {
        restore_error_handler();
    }
}

6. Alternative 3: try/catch with targeted exception types

For APIs that already throw, the @ operator is unnecessary in the first place, error handling belongs directly in a try/catch block with the most specific exception type available. A good example is json_decode: without an extra flag the function simply returns null on invalid JSON and requires a manual check with json_last_error. With the JSON_THROW_ON_ERROR flag it throws a JsonException instead, which can be caught explicitly.

The difference to error suppression is decisive: a catch block catches exactly the defined exception type and lets every other, unexpected error pass upward unhindered, where it remains visible and can be logged. The @ operator knows no such distinction, it suppresses everything inside the expression indiscriminately, regardless of the actual cause.

<?php

declare(strict_types=1);

function parseJsonConfig(string $json): array
{
    try {
        /** @var array<string, mixed> $data */
        $data = json_decode($json, true, 512, JSON_THROW_ON_ERROR);
        return $data;
    } catch (JsonException $exception) {
        throw new RuntimeException(
            'Could not parse configuration: ' . $exception->getMessage(),
            previous: $exception,
        );
    }
}

7. Complete example: a safe file read function

Combining the upfront check with set_error_handler produces a function that throws a precise, context rich exception for every conceivable failure case, instead of silently returning false. This version fully replaces the antipattern shown earlier and makes every failure explicit and handleable in the caller, without needing a single @ operator anywhere.

The extra effort compared to the suppressed version is small, usually just a few additional lines, but it pays off with every production incident, because the error message points straight at the actual cause. In codebases that consistently work this way, the average time to diagnose an error drops noticeably, because nobody has to guess anymore where in the code an operation actually failed.

<?php

declare(strict_types=1);

function readFileSafely(string $path): string
{
    if (!is_readable($path)) {
        throw new RuntimeException(sprintf('File not readable: %s', $path));
    }

    return withErrorsAsExceptions(static function () use ($path): string {
        $handle = fopen($path, 'r');
        $content = fread($handle, filesize($path));
        fclose($handle);

        return $content;
    });
}

8. The few legitimate remaining cases

There are a handful of very narrowly scoped situations where the @ operator was historically accepted, for example with certain legacy extensions that neither throw exceptions nor offer a usable return value for error detection. Even in these cases the suppression should be scoped as tightly as possible around exactly one expression and justified with a comment explaining why none of the alternatives above applies.

In modern PHP 8.4 the number of such cases has become quite small, since almost every relevant core function either already throws or can be made to via documented flags. A pragmatic rule of thumb: every use of @ in new code should be challenged in code review, and existing occurrences should gradually be replaced with one of the three alternatives shown here.

9. Tooling: catching violations automatically

Instead of relying on review discipline, avoiding the @ operator can be enforced technically. PHP_CodeSniffer ships a ready made sniff, Generic.PHP.NoSilencedErrors, that fails the build on every occurrence. PHPStan does not detect suppressed expressions directly out of the box, but extensions such as phpstan-strict-rules flag related suspicious patterns, like unchecked false returns following a suppressed call.

In the CI pipeline a simple additional safeguard is worthwhile: a grep check for the pattern @ followed by a function name across all PHP files outside test directories, combined with an explicit exception list for the few justified remaining cases from the previous section. That keeps the @ operator visible and controlled, instead of quietly spreading through new code unnoticed.

10. Summary

11. FAQ: Error Suppression Without @