Viewed   93 times

I have a simple custom error handler that writes in a error log file some useful debug infos.

it's work for everything but it's not get triggered for FATAL error.

Any way to solve this?

Currently to bypass this circumstance I have registered a shutdown function too that checks error_get_last()

 Answers

4

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.

Sunday, October 16, 2022
 
2

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.

Tuesday, August 30, 2022
2

No. Fatal errors are fatal. Even if you were to write your own error handler or use the @ error suppression operator, E_FATAL errors will still cause the script to halt execution.

The only way to handle this is to use function_exists() (and possibly is_callable() for good measure) as in your example above.

It's always a better idea to code defensively around a potential (probable?) error than it is to just let the error happen and deal with it later anyway.

EDIT - php7 has changed this behavior, and undefined functions/methods are catchable exceptions.

Wednesday, November 2, 2022
 
mage_xy
 
5

This works for me:

function shutdown() {
    $error = error_get_last();
    if ($error['type'] === E_ERROR) {
        // fatal error has occured
    }
}

register_shutdown_function('shutdown');

spl_autoload_register('foo'); 
// throws a LogicException which is not caught, so triggers a E_ERROR

However, you probably know it already, but just to make sure: you can't recover from a E_ERROR in any way.

As for the backtrace, you can't... :( In most cases of a fatal error, especially Undefined function errors, you don't really need it. Pinpointing the file/line where it occured is enough. The backtrace is irrelevant in that case.

Monday, October 31, 2022
 
2

Because you can not catch the exception which is happening at Application.Exit(), this sounds like you are facing a bug I've seen before. Please try to comment out all the lines where you set the Font attribute. If the application exists without the error message, you are facing a bug which affects NetCF 3.5 at WinCE 6.0 only. See this link for more information.

Friday, August 5, 2022
 
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :