No Error, Wrong Answer: Debugging Silent Failure in PHP

An exception hands you a file and a line. A silent failure hands you nothing, because from the engine’s point of view nothing went wrong: every statement executed, every function returned, and the result is simply not the result you wanted.

That absence changes the method completely. With a crash you work backward from a known point. With a silent failure you do not have a point yet, and the first job is to manufacture one.

The point you are looking for has a precise definition, and it is worth stating before any technique: the first place in the flow where the data stops matching what you believe about it. Everything upstream of that point is fine and can be ignored. Everything downstream is contaminated and will mislead you. Find that boundary and the bug is usually inside a handful of lines.

Step one: write down what you expect, as a value

This sounds like a formality and it is the step that does the work.

Not “the total should be right”. A value: at the end of this function, $total should be 48.60, and $items should have 3 elements. Not “the user should be logged in”, but get_current_user_id() should return 7 here.

Two things happen when you write it down. You often discover you do not actually know, which is itself the finding, and you now have something a check can be written against. A vague expectation cannot be tested, so a vague expectation keeps you reading code instead of measuring it.

Step two: bisect the flow, do not read it

Reading code to find a silent failure is the slowest available method, because you are looking for the place where your own belief about the code is wrong, and you will read straight past it. You believed it when you wrote it and you will believe it again now.

So measure instead, and bisect. Pick a point roughly halfway through the flow and dump the state there.

error_log('checkout: ' . var_export([
    'items' => count($items),
    'subtotal' => $subtotal,
    'user' => get_current_user_id(),
], true));

If the data is already wrong at the midpoint, the bug is upstream and you halve again. If it is still right, the bug is downstream and you halve the other way. Six or seven of these narrow almost any request down to a few lines, without understanding any of the code in between.

Two practical notes on that snippet. var_export with true returns a string rather than printing it, which is what you want inside a log call, and it renders types visibly, so '0' and 0 and false do not all arrive looking the same. And error_log writes to the server’s log rather than the page, so it does not break output, does not corrupt a JSON response, and does not leak anything to a visitor if you forget one. Do not use var_dump or print_r without the return argument in a request that produces output. You will spend twenty minutes debugging your own debugging.

Step three: the four places silent failures actually live

Once you have narrowed it, the fault is usually one of four shapes. In rough order of how often they turn out to be the answer.

A comparison that is not the comparison you think

Loose comparison is the single most productive place to look, and PHP’s behavior here changed, which means old advice and old memories are actively misleading.

PHP 8 changed how a string is compared to a number. Under PHP 7, 0 == "foo" evaluated to true, because the string was converted to a number first. Under PHP 8 it evaluates to false, because when a number is compared to a non-numeric string the number is now converted to a string instead. Code written around the old behavior, and mental models formed under it, both quietly change meaning on an upgrade. Nothing errors. The branch simply goes the other way now.

The other members of this family, all of which run clean and none of which mean what they look like:

if (strpos($haystack, $needle)) { }        // false when the match is at position 0
if (empty($value)) { }                     // true for "0", 0, 0.0, "", [], null, false
if (in_array($id, $ids)) { }               // loose by default

The fixes are mechanical and worth applying on sight:

if (strpos($haystack, $needle) !== false) { }
if (!isset($value) || $value === '') { }
if (in_array($id, $ids, true)) { }

in_array‘s third argument is the one that catches real bugs. Without it, a string "7abc" and an integer 7 can match each other depending on the values involved, and an id that came out of a request as a string behaves differently from the same id that came out of the database as an integer.

A function whose return shape is not what you assumed

The classic, because it produces valid output that is the wrong type on the other side of an encoder:

$active = array_filter($users, fn($u) => $u->active);
echo json_encode($active);

array_filter preserves keys. Remove the middle element of a three element list and you have keys 0 and 2, which is no longer a list, so json_encode emits a JSON object {"0":...,"2":...} rather than an array. The PHP side is fine. The JavaScript side receives something it cannot iterate as an array and either renders nothing or renders it wrong. Nothing anywhere throws.

$active = array_values(array_filter($users, fn($u) => $u->active));

The same shape appears with array_merge renumbering integer keys while the + operator keeps the left hand side’s, and with functions that return null rather than an empty array on no result.

A value that was fine until it was mutated somewhere you were not looking

A reference in a foreach, an object passed where a copy was assumed, a static or global holding state between calls, a filter or hook someone else registered against the same data. The give away is that the value is correct at one measurement and wrong at the next with no assignment in between, which is exactly what bisecting surfaces and reading does not.

Arithmetic that is correct and still not equal

if (0.1 + 0.2 == 0.3) { }   // false

Binary floating point cannot represent those values exactly, so a total computed one way and a total computed another way can differ in the last bits and compare unequal while printing identically. Money is the usual victim. Compare within a tolerance, or hold currency in the smallest unit as integers.

Step four: pin it before you fix it

When you find the boundary, resist fixing it immediately. Write the check first.

// Reproduces the bug: returns 48.60, expected 54.00
assert($cart->total() === 54.00);

A failing check before the change and a passing one after is the difference between knowing you fixed it and hoping. Silent failures are the category where “it looks right now” is least trustworthy, because looking right is the exact condition that let the bug ship in the first place.

This is also the reason a green test suite is not evidence on its own. A test written by reading the implementation asserts what the implementation does, which is precisely the wrong reference point when the implementation is what is wrong. That failure mode has become much more common where the code and its tests were produced in the same pass, and it is worth reading on its own: when code passes its tests and is still wrong covers what does catch it.

The habit that prevents most of them

Silent failure is, almost always, a bad value that was allowed to travel. The cheapest structural defense is to stop letting it travel: check the shape at the boundary where data enters your code, and fail loudly there rather than producing a wrong answer three layers later.

public function total(array $lines): float
{
    foreach ($lines as $line) {
        if (!isset($line['qty'], $line['price'])) {
            throw new InvalidArgumentException('line missing qty or price');
        }
    }
    // ...
}

That converts a silent failure into a crash, and a crash tells you a file and a line. Turning a wrong answer into an exception is not a workaround. It is the fix, because the wrong answer was always there and the only thing you changed is how early you find out.

The short version

1. Write down the expected value, concretely.
2. Bisect the flow with logged state, do not read the code.
3. Find the first point where the data stops matching the expectation.
4. Check the four usual shapes: loose comparison, return shape, unnoticed mutation, float equality.
5. Pin it with a failing assertion, then fix it.
6. Add the boundary check that would have made it crash instead.