Best Practices for Catching Fatal Errors in PHP

Undeniably the most frustating thing about PHP as a language has to be it's handling of fatal errors. It's next to impossible in PHP to catch a fatal error before it reaches the browser window. Worse  is that a fatal error will not invoke any error handler set by set_error_handler() and will just stop all script execution.

There has to be a posts  numbering in the hundreds of thousands all across the internet.  PHP developers desparate to avoid fatal errors and catch them as  exceptions. Doing a Google Search : "php how to catch fatal error" reveals About 460,000 results. The release of PHP7 will reduce this significantly.


It's  a sea of explanations and attempts to circumvent something that is so ingrained in PHP that it causes many to jump ship to another programming language. Frameworks using complicated work arounds and design pattern patchworks. These capture error messages but do nothing for the halt in program execution. There's one that probably will not come up in any FIG meeting; a PSR for fatal error-handling. Sorry, I just get sick of everyone promoting  the thinking that they can fix PHP by using PHP in a framework.

PHP7 Saves the day

Now with  PHP7 developers will no longer have to suffer the indignity of using ini_set('display_errors','0'); or the endure the pain of  the use of  the "@"  suppression character.

Frustration sets in from both  corners. On one side th developer who is pressured and feels they have no othre choice. On the other those who know better  and  hope that some kind guidance will prove to be an effective deterrent against it's use.

Note: Firstly, I realise 99% of PHP developers use the error suppression operator (I used to be one of them), so I'm expecting any PHP dev who sees this to down vote me, but please bookmark this so that you can come back and change it to an up vote in a couple of years when you realise I was right. -- stackoverflow

Catch Me if You Can

So what's the best practice for fatal error handling in any situation? Well in PHP 5 there aren't any. But in the upcoming PHP7 release there  will be rainbows and unicorns.

The thing is you'll have to  write code in a manner that you would not have done before. Use architecture that you avoided because of fatal error that could not be caught.

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.

Everyone is talking about the performance speed of PHP7. Fatal errors will be the number two reason in my mind for switching to PHP 7 and dropping PHP5 entirely. But it will require vigilant thinking  on the developers part and re-factoring situations that before were left to chance. So the best practice is to  catch  those errors and write code that  includes the possibility of error.  Stop thinking you're so bad ass that an error would not dare  show it's evilness in your program.

Two Steps Backward

The problem is that  PHP frameworks and  Content Management systems will probably not re-factor their code and provide better and more robust solutions by upgrading fully to PHP 7. 

Writing Code to Support PHP 5.x and 7 Exceptions
To catch any exception in PHP 5.x and 7 with the same code, multiple catch blocks can be used, catching Throwable first, then Exception. Once PHP 5.x support is no longer needed, the block catching Exception can be removed.

Expect to see many fixes at Github and in the patch queues at Drupal.org using this bit of code

try {
    // Code that may throw an Exception or Error.
} catch (Throwable $t) {
    // Executed only in PHP 7, will not match in PHP 5.x
} catch (Exception $e) {
    // Executed only in PHP 5.x, will not be reached in PHP 7
}

They will be creating a code base for maintaining backwards compatibility. Delegating code to handle a best case scenario of an older version of PHP. When they should be writing it forward to the latest version. This unfortunately is the status quo for PHP open source projects. See Open Source Zombies take Over the World!. Hopefully open source project will make better choices and not use this tool as another excuse to re-write PHP functionality with yet another design pattern.

Users are able to create Error as well as extend Error to create your own hierarchy of Error classes. This poses an important question: what situations should throw an instance of a class extending Exception and what situations should throw an instance of a class extending Error?

Write it Again Sam

Before you  start writing your new code for PHP5 or try to fix existing code you should read Aaron Piotrowski's Throwable Exceptions and Errors in PHP 7. Do yourself a favor read it fully twice! Then start coding a second PHP7 only copy.