Update:
I guess I didn’t make the purpose quite clear here. This method will allow you to show custom error messages when PHP hits a fatal error. The shutdown function will always run.
Scripts tend to die, and that’s not usually nice. We do not want to show the user a fatal error nor a blank page (display errors off) . PHP has a function called register_shutdown_function which lets us set up a function which is called at execution shutdown. What this means is that our function will be executed when our script is done executing / dying and PHP execution is about to shut down. By setting up a variable to false at the start of our script, and setting it to true at the very end of the script we can have our shutdown function check if the script completed successfully or not. If our variable is still false we know that we never made it to the last line of our script, hence it died somewhere. I’ve prepared a very basic sample which shows how you can give the user some proper feedback if a fatal error should arise. You’d want to turn of display of fatal errors for this to look nice.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | $clean = false; function shutdown_func(){ global $clean; if (!$clean){ die("not a clean shutdown"); } } register_shutdown_function('shutdown_func'); $a = 1; $a = new FooClass(); // will fail with fatal $clean = true; ?> |
As you can see, the shutdown_func prints something if the clean variable isn’t set to true when the shutdown function runs. This should of course be wrapped in a class (and NOT use globals), and for something more usable I recommend checking EZ Components way of doing this.
#1 by Josh - March 16th, 2008 at 13:45
This is definitely useful in a CLI context, where a user may decide to prematurely terminate a long-running CLI script, and it can clean up after itself – maybe even print some last-minute report info. The Windows ping utility works similarly.
However, in my opinion, shutdown functions have no place in a web-based context. Errors should be handled properly – caught, or better still, avoided in the first place. On the occasion that a system issue, such as a power outage (and brief UPS lifeline), causes your script to execute, you could have hundreds of PHP/Apache threads running around trying to clean up after themselves when the system should be halting.
I guess it comes down to one key issue – you attempt to die in grace when you should have no need to die at all, or should not waste CPU cycles with grace on the odd occasion you do.
#2 by eirikhoem - March 17th, 2008 at 14:20
@Josh
Thanks for the feedback. I fully agree that it can be very usable in a CLI context, and I do use it in several scripts which needs summaries etc.
Did you see the discussion over at Richard Heyes (“phpguru”) blog?
He made a follow up on my post where he states his disagreements regarding the usage I present. I agree that avoiding / catching errors is a must, but this code we have here actually lets the developer present information when a fatal error comes along. I don’t think I made that clear enough in my initial post, so I’ve updated it.
I did not consider your point regarding the PHP/Apache thread cleaning up when writing this post, but I do find it pretty interesting.
#3 by zhaiduo - March 19th, 2008 at 08:37
Can’t see the difference, whatever $clean is true or not. But I think register_shutdown_function is some useful. B-)
#4 by admin - March 20th, 2008 at 12:48
@zhaiduo:
$clean never gets set to true since the script fails with a fatal error at line 13. The shutdown_func gets executed anyways, and it checks if $clean is true or not. If it’s false it will output info.
#5 by Etibar - August 26th, 2008 at 09:03
PHP documentation says that “The registered shutdown functions are called after the request has been completed (including sending any output buffers), so it is not possible to send output to the browser using echo() or print(), or retrieve the contents of any output buffers using ob_get_contents(). ”
Am I missing anything or… ?
#6 by Daniel - August 26th, 2008 at 09:04
This functionality can be used in web application, IMHO, if you have large legacy codebase which runs as complex CMS / CRM.
For example if you work with very large (and very old) system usually there is no enough time (and money) to write all legacy stuff from the beginning or even do necessary refactoring. New code very often uses legacy functionality.
Of course QA are not able to test everything and unit tests do not exist for legacy functionality. As a result, from time to time fatal errors can occur in production environment (user sees white screen or not completed layout).
register_shutdown_function could help with display user friendly message to make sure customer will not be wondering what just has happened.