Set_Error_Handler() Doesn't Work for Fatal Error

set_error_handler() doesn't work for FATAL error

Nope, that's just a limitation of set_error_handler(); it doesn't handle all errors.

The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler() is called.

The register_shutdown_function() and error_get_last() is a decent workaround.

PHP - set_error_handler doesn't catch mysqli errors

As you can see, MySQLi use Exception (and perhaps most of the new features in PHP stop using obsolete error API and shift to Exception API). For the differents between Exception and Error you can find it here

Your example code throw an BadMethodCallException which is not caught by set_error_handler and bubble up to become a Fatal error (notice that set_error_handler cannot catch fatal error)

So the solution is using Exception and its complements: try ... catch block, or set_exception_handler.

Regards,

PHP : Custom error handler - handling parse & fatal errors

Simple Answer: You can't. See the manual:

The following error types cannot be
handled with a user defined function:
E_ERROR, E_PARSE, E_CORE_ERROR,
E_CORE_WARNING, E_COMPILE_ERROR,
E_COMPILE_WARNING, and most of
E_STRICT raised in the file where
set_error_handler() is called.

For every other error, you can use set_error_handler()

EDIT:

Since it seems, that there are some discussions on this topic, with regards to using register_shutdown_function, we should take a look at the definition of handling: To me, handling an error means catching the error and reacting in a way that is "nice" for the user and the underlying data (databases, files, web services, etc.).

Using register_shutdown_function you cannot handle an error from within the code where it was called, meaning the code would still stop working at the point where the error occurs. You can, however, present the user with an error message instead of a white page, but you cannot, for example, roll back anything that your code did prior to failing.

Why is my custom error handler not called?

First, you need to make your error handling function return true. From set_error_handler:

If the function returns FALSE then the normal error handler continues.

Second, be aware that fatal errors aren't handled by set_error_handler. You need to use register_shutdown_function as well. So your code should look like this:

// Handles non-fatal errors
function handleError($code, $text, $file, $line) {
    var_dump($code);
    return true;
}
set_error_handler('handleError');

// Handles fatal errors
function fatalShutdown() {
    var_dump(error_get_last());
}
register_shutdown_function('fatalShutdown');

What happens with set_error_handler() on PHP7 now that all errors are exceptions?

Aaron Piotrowski (the guy who made the new Error-Exception system) has a great blog on this. I think the key point you need to understand is this

In PHP 7, an exception will be thrown when a fatal and recoverable error (E_ERROR and E_RECOVERABLE_ERROR) occurs, rather than halting script execution. Fatal errors still exist for certain conditions, such as running out of memory, and still behave as before by immediately halting script execution. An uncaught exception will also continue to be a fatal error in PHP 7. This means if an exception thrown from an error that was fatal in PHP 5.x goes uncaught, it will still be a fatal error in PHP 7.

Note that other types of errors such as warnings and notices remain unchanged in PHP 7. Only fatal and recoverable errors throw exceptions.

To put this a different way consider this

• set_exception_handler() - Function to handle Exceptions by default (as of PHP 7.0 this can handle all Throwables, so it can catch recoverable errors)
• set_error_handler() - Function to handle recoverable errors

In other words, their functionality didn't change. Anything that triggers them in PHP5 will trigger them in PHP7, it's just that, now, you can use a try-catch block at the script level to handle a specific error.

PHP: How to use set_error_handler() to properly deal with all errors except notices?

set_error_handler('some_handler',E_ALL & ~E_NOTICE & ~E_USER_NOTICE);

Or, if you really want all,

set_error_handler('some_handler',-1 & ~E_NOTICE & ~E_USER_NOTICE);

Alternatively, you can just set it to use all errors, and just ignore it if they're not in error_reporting (which you set to the same value as the above line, also, the @ operator works then):

....
if(!($errno & error_reporting())) return true;
switch($errno){
....

How do I handle parse and fatal errors?

If it can't parse your script, it won't be able to parse your custom error handler.

You should have display_errors off in your php.ini and also set error_reporting to none when your site is in production.

Also, I believe set_error_handler() can handle fatal errors.

How to catch undefined functions with set_error_handler in PHP

set_error_handler is designed to handle errors with codes of: E_USER_ERROR | E_USER_WARNING | E_USER_NOTICE. This is because set_error_handler is meant to be a method of reporting errors thrown by the user error function trigger_error.

However, I did find this comment in the manual that may help you:

"The following error types cannot be handled with a user defined function: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR, E_COMPILE_WARNING, and most of E_STRICT raised in the file where set_error_handler() is called."

This is not exactly true. set_error_handler() can't handle them, but ob_start() can handle at least E_ERROR.

<?php

function error_handler($output)
{
    $error = error_get_last();
    $output = "";
    foreach ($error as $info => $string)
        $output .= "{$info}: {$string}\n";
    return $output;
}

ob_start('error_handler');

will_this_undefined_function_raise_an_error();

?>

Really though these errors should be silently reported in a file, for example. Hopefully you won't have many E_PARSE errors in your project! :-)

As for general error reporting, stick with Exceptions (I find it helpful to make them tie in with my MVC system). You can build a pretty versatile Exception to provide options via buttons and add plenty of description to let the user know what's wrong.

---

Related Topics