restore_error_handler
Pops the most recent error handler off the stack and reactivates the previous one.
restore_error_handler(): true- Added in PHP 4.0.1
Return value
trueAlways returns true.
restore_error_handler() pops the handler installed by the most recent set_error_handler() call off PHP's internal handler stack and makes the one below it active again, together with the error_levels mask it was originally registered with. The restored handler may be another user handler or PHP's built-in one.
It is a stack, not a toggle
Every set_error_handler() pushes; every restore_error_handler() pops exactly one level. Three sets need three restores to get back to the default. If you call it more times than you called set_error_handler(), nothing bad happens — the built-in handler simply stays active and no error is raised — but you may have popped a handler that another part of the application installed and expected to keep.
Pair it with finally
The common bug is installing a handler, running code that throws, and never restoring, leaving the rest of the request with the wrong handler. Wrap the work in try/finally so the pop always happens:
set_error_handler($temp);
try { risky(); } finally { restore_error_handler(); }In PHP 8.5, get_error_handler() lets you confirm what is active before and after, which is worth doing in library teardown code.
Example
When to use it
- Remove a temporary handler after wrapping one risky legacy call
- Restore normal error handling in a test's tearDown method
- Unwind nested handlers installed by a plugin during bootstrap
Frequently asked questions
What is the difference between restore_error_handler and set_error_handler(null)?
restore_error_handler() pops one level off the stack and reinstates whatever was active before, while set_error_handler(null) installs the built-in handler as a new entry on top. Use restore to unwind, not null.
Does restore_error_handler ever return false?
No, it always returns true, even when the handler stack is already empty. Use get_error_handler() in PHP 8.5 to find out what is actually active.
How many times do I need to call restore_error_handler?
Once for each set_error_handler() call you made, because handlers form a stack. Calling it more often is not an error but may remove a handler another component installed.
More examples
Always restore, even on failure
The callback throws, so the return statement never runs, but finally still pops the handler. The final NULL proves error handling was left in its original state despite the exception.
<?php
function withQuietErrors(callable $fn): mixed {
set_error_handler(fn(int $n, string $m): bool => true); // swallow everything
try {
return $fn();
} finally {
restore_error_handler();
}
}
try {
withQuietErrors(function () { throw new RuntimeException('boom'); });
} catch (RuntimeException $e) {
echo 'caught: ', $e->getMessage(), "\n";
}
var_dump(get_error_handler()); // NULL - the finally block still ranNested handlers unwind one level at a time
The output is "inner: one" then "outer: two". Each restore removes exactly one layer, which is why two set calls need two restores before the built-in handler returns.
<?php
set_error_handler(fn(int $n, string $m): bool => print("outer: {$m}\n"));
set_error_handler(fn(int $n, string $m): bool => print("inner: {$m}\n"));
trigger_error('one', E_USER_NOTICE); // inner
restore_error_handler();
trigger_error('two', E_USER_NOTICE); // outer
restore_error_handler();
var_dump(get_error_handler()); // NULLExtra restores are harmless but wasteful
The return value is always true, so it never signals whether anything was actually popped. Extra calls raise no error, but in a larger application they would quietly discard a handler installed by another component.
<?php
set_error_handler(fn(int $n, string $m): bool => print("custom: {$m}\n"));
var_dump(restore_error_handler()); // bool(true)
var_dump(restore_error_handler()); // bool(true) - stack already empty
var_dump(restore_error_handler()); // bool(true)
var_dump(get_error_handler()); // NULL
Discussion