Ando_ErrorFactory

Notice that the lines starting with “PHP” belong to STDERR (redirected to STDOUT, controlled by the ´error_reporting´ call), while the rest belong to the real STDOUT.

The take away is that we forcefully triggered an E_CORE_ERROR (fact confirmed by the STDERR portion) and our shutdown handler was able to log it (fact confirmed by the STDOUT portion). Given that such an error is a non catchable shutdown error, there is no other way to get a look at it than from inside a shutdown handler.

Here is what happens when instead we forcefully trigger an E_RECOVERABLE_ERROR:

The presence of the ´– e n d –´ line in the output confirms, as expected, that E_RECOVERABLE_ERROR is not a shutdown error. Thanks to that, we had a chance to get to the backtrace from our non shutdown error handler, while the STDERR didn’t get written to because we signaled to PHP we successfully handled the error by returning ´true´. In fact, here is what would happen if we returned ´false´:

As you see, by returning ´false´, we told PHP that we didn’t successfully handle the error and to continue its default course, which in this case, being E_RECOVERABLE_ERROR a shutdown error by default, consisted in shutting down the script. As a confirmation, notice the absence of the ´– e n d –´ line in the output.

A fun fact I discovered while programming this class is that a fatal error is not necessarily a non-catchable shutdown error. In fact, both E_RECOVERABLE_ERROR and E_USER_ERROR are catchable shutdown errors. Likewise, E_PARSE, E_CORE_WARNING and E_COMPILE_WARNING are non catchable non shutdown errors. For each of these variations ErrorFactory has a corresponding method to return that set of errors.

{[ .example2 | 1.hilite(=php=) ]}

Note that the non_shutdown_error and shutdown_error handlers are included as a proof of concept. You are supposed to program yourself proper handlers, if and how you see fit. But you can certainly use them for testing something out, like I did above.