restore_error_handler
Used after changing the error handler function using set_error_handler() , to revert to the previous error handler (which could be the built-in or a user defined function).
Parameters
This function has no parameters.
Return Values
Always returns true .
Examples
Example #1 restore_error_handler() example
Decide if unserialize() caused an error, then restore the original error handler.
function unserialize_handler ( $errno , $errstr )
echo «Invalid serialized value.\n» ;
>
$serialized = ‘foo’ ;
set_error_handler ( ‘unserialize_handler’ );
$original = unserialize ( $serialized );
restore_error_handler ();
?>
The above example will output:
See Also
- error_reporting() — Sets which PHP errors are reported
- set_error_handler() — Sets a user-defined error handler function
- restore_exception_handler() — Restores the previously defined exception handler function
- trigger_error() — Generates a user-level error/warning/notice message
- Error Handling Functions
- debug_backtrace
- debug_print_backtrace
- error_clear_last
- error_get_last
- error_log
- error_reporting
- restore_error_handler
- restore_exception_handler
- set_error_handler
- set_exception_handler
- trigger_error
- user_error
Restore_error_handler()
When it comes to PHP development, error handling is an essential aspect that should never be overlooked. In this article, we’ll take a deep dive into PHP error handling and restoration using PHP error restore error handlers. We’ll start by understanding what error handlers are, their significance in PHP development, and how they work. We’ll then move on to restoring error handlers using PHP restore_error_handler() function, and provide a practical example.
What are Error Handlers in PHP?
Error handlers are PHP functions that handle runtime errors that occur when executing PHP code. PHP provides different types of error handlers, such as error_reporting(), set_error_handler(), and restore_error_handler(), that allow you to handle errors and warnings that occur when running PHP code.
The Importance of Error Handlers in PHP
PHP error handlers are crucial because they help you identify and debug runtime errors, which can help improve the quality of your PHP code. Without error handlers, runtime errors can cause your PHP application to crash, leading to a poor user experience. Additionally, error handlers allow you to define custom error messages that provide meaningful information to the user, making it easier to understand and fix errors.
How do Error Handlers work in PHP?
PHP error handlers work by intercepting runtime errors that occur when executing PHP code. When an error occurs, PHP stops executing the code and invokes the registered error handler. The error handler then processes the error and provides a customized error message to the user.
Restoring Error Handlers in PHP
In PHP, it’s possible to change the default error handler using the set_error_handler() function. However, in some cases, you may want to restore the original error handler. To do this, you can use the restore_error_handler() function.
Example of Restoring Error Handlers in PHP
sequenceDiagram participant PHP_Application participant User participant Error_Handler User->>+PHP_Application: Triggers error in PHP code PHP_Application->>+Error_Handler: Error handler intercepts the error Error_Handler->>+User: Custom error message is displayed to the user User->>PHP_Application: User clicks button to restore default error handler PHP_Application->>Error_Handler: restore_error_handler() function is called Error_Handler-->>PHP_Application: Default error handler is restored
Here’s an example of restoring the default error handler in PHP:
// Custom error handler function function custom_error_handler($errno, $errstr, $errfile, $errline) < // Custom error message echo "Error: [$errno] $errstr - $errfile:$errline"; > // Set custom error handler set_error_handler("custom_error_handler"); // Trigger an error undefined_function(); // Restore default error handler restore_error_handler(); ?>Conclusion
In conclusion, error handling is an essential aspect of PHP development that can significantly impact the quality of your PHP code. PHP error handlers, such as restore_error_handler(), allow you to handle runtime errors and provide custom error messages that can improve the user experience. By understanding the significance of error handlers, you can write better PHP code that is more efficient and user-friendly.
See Also
I keep seeing qualification lists for error types/error-nums as arrays; In user notes and in the manual itself. For example, in this manual entry’s example, when trying to seperate behavior for the variable trace in the error report:
// set of errors for which a var trace will be saved
$user_errors = array( E_USER_ERROR , E_USER_WARNING , E_USER_NOTICE );if ( in_array ( $errno , $user_errors )) //. whatever
>//. ?>
I was under the impression that PHP error code values where bitwise flag values. Wouldn’t bitwise masking be better? So I propose a slightly better way:
$user_errors = E_USER_ERROR | E_USER_WARNING | E_USER_NOTICE ;
if ( $errno & $user_errors ) //. whatever
>//. ?>
Or for those of you who don’t like the idea of using an integer as the condition in an if statement:if (( $errno & $user_errors ) > 0 ) //. whatever
>
?>I think that’s much more efficient than using _yet another_ array() constuct and an in_array().
If I am wrong, and the E_* constants aren’t supposed to be used in this fashion (ie, the constans aren’t guaranteed to be bitwise, which would be odd since that’s how they’re setup in the php.ini file), then delete me. I just don’t see why one should be using arrays when bitwise comparisons will work, considering the bitwise method should be MUCH more efficient.
Although the root user writes to the files ‘error_log’ and ‘access_log’, the Apache user has to own the file referenced by ‘error_log = filename’ or no log entries will be written.
; From php.ini
[root@www logs]$ ls -l /usr/local/apache/logs/php.errors
; Log errors to specified file.
error_log = /usr/local/apache/logs/php.errors
-rw-r—r— 1 nobody root 27K Jan 27 16:58 php.errorsPHP5 only (only tested with php5.0).
If you, for some reason, prefer exceptions over errors and have your custom error handler (set_error_handler) wrap the error into an exception you have to be careful with your script.
Because if you, instead of just calling the exception handler, throws the exception, and having a custom exception handler (set_exception_handler). And an error is being triggered inside that exception handler, you will get a weird error:
«Fatal error: Exception thrown without a stack frame in Unknown on line 0»This error is not particulary informative, is it? 🙂
This example below will cause this error.
class PHPErrorException extends Exception
private $context = null ;
public function __construct
( $code , $message , $file , $line , $context = null )
parent :: __construct ( $message , $code );
$this -> file = $file ;
$this -> line = $line ;
$this -> context = $context ;
>
>;function error_handler ( $code , $message , $file , $line ) throw new PHPErrorException ( $code , $message , $file , $line );
>function exception_handler ( Exception $e )
<
$errors = array(
E_USER_ERROR => «User Error» ,
E_USER_WARNING => «User Warning» ,
E_USER_NOTICE => «User Notice» ,
);echo $errors [ $e -> getCode ()]. ‘: ‘ . $e -> getMessage (). ‘ in ‘ . $e -> getFile ().
‘ on line ‘ . $e -> getLine (). «\n» ;
echo $e -> getTraceAsString ();
>set_error_handler ( ‘error_handler’ );
set_exception_handler ( ‘exception_handler’ );// Throw exception with an /unkown/ error code.
throw new Exception ( ‘foo’ , 0 );
?>There are however, easy fix for this as it’s only cause is sloppy code.
Like one, directly call exception_handler from error_handler instead of throwing an exception. Not only does it remedy this problem, but it’s also faster. Though this will cause a `regular` unhandled exception being printed and if only «designed» error messages are intended, this is not the ultimate solution.So, what is there to do? Make sure the code in exception_handlers doesn’t cause any errors! In this case a simple isset() would have solved it.
If you are using PHP as an Apache module, your default behavior may be to write PHP error messages to Apache’s error log. This is because the error_log .ini directive may be set equal to «error_log» which is also the name of Apache’s error log. I think this is intentional.
However, you can separate Apache errors from PHP errors if you wish by simply setting a different value for error_log. I write mine in the /var/log folder.
Note the example code listed here calls date() every time this is called. If you have a complex source base which calls the custom error handler often, it can end up taking quite a bit of time. I ran a profiler on som code and discovered that 50% of the time was spent in the date function in this error handler.
When configuring your error log file in php.ini, you can use an absolute path or a relative path. A relative path will be resolved based on the location of the generating script, and you’ll get a log file in each directory you have scripts in. If you want all your error messages to go to the same file, use an absolute path to the file.
In some application development methodologies, there is the concept of an application root directory, indicated by «/» (even on Windows). However, PHP does not seem to have this concept, and using a «/» as the initial character in a log file path produces weird behavior on Windows.
If you are running on Windows and have set, in php.ini:
You will get some, but not all, error messages. The file will appear at
and contain internally generated error messages, making it appear that error logging is working. However, log messages requested by error_log() do NOT appear here, or anywhere else, making it appear that the code containing them did not get processed.
Apparently on Windows the internally generated errors will interpret «/» as «C:\» (or possibly a different drive if you have Windows installed elsewhere — I haven’t tested this). However, the error_log process apparently can’t find «/» — understandably enough — and the message is dropped silently.
It is totally possible to use debug_backtrace() inside an error handling function. Here, take a look:
function errorHandler ( $errno , $errstr , $errfile , $errline , $errcontext )
echo ‘Into ‘ . __FUNCTION__ . ‘() at line ‘ . __LINE__ .
«\n\n—ERRNO—\n» . print_r ( $errno , true ).
«\n\n—ERRSTR—\n» . print_r ( $errstr , true ).
«\n\n—ERRFILE—\n» . print_r ( $errfile , true ).
«\n\n—ERRLINE—\n» . print_r ( $errline , true ).
«\n\n—ERRCONTEXT—\n» . print_r ( $errcontext , true ).
«\n\nBacktrace of errorHandler()\n» .
print_r ( debug_backtrace (), true );
>function a ( )
//echo «a()’s backtrace\n».print_r( debug_backtrace(), true);
asdfasdf ; // oops
>function b ()
//echo «b()’s backtrace\n».print_r( debug_backtrace(), true);
a ();
>Into errorhandler() at line 9
—ERRSTR—
Use of undefined constant asdfasdf — assumed ‘asdfasdf’Backtrace of errorHandler()
[1] => Array
Array
(
[0] => Array
(
[function] => errorhandler
[args] => Array
(
[0] => 8
[1] => Use of undefined constant asdfasdf — assumed ‘asdfasdf’
[2] => /home/theotek/test-1.php
[3] => 23
[4] => Array
(
)
(
[file] => /home/theotek/test-1.php
[line] => 23
[function] => a
) [2] => Array
(
[file] => /home/theotek/test-1.php
[line] => 30
[function] => a
[args] => Array
(
) [3] => Array
(
[file] => /home/theotek/test-1.php
[line] => 33
[function] => b
[args] => Array
(
)So, the first member of the backtrace’s array is not really surprising, except from the missing «file» and «line» members.
The second member of the backtrace seem the be a hook inside the zend engine that is used to trigger the error.
Other members are the normal backtrace.