php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #41418 Mechanism for trapping fatal errors
Submitted: 2007-05-17 17:05 UTC Modified: 2007-05-17 23:45 UTC
From: public at syranide dot com Assigned:
Status: Not a bug Package: Feature/Change Request
PHP Version: 5.2.2 OS:
Private report: No CVE-ID: None
 [2007-05-17 17:05 UTC] public at syranide dot com
Description:
------------
Something I've been longing to see is a way to catch fatal errors so that PHP doesn't print out errors to the clients or worse, nothing at all. Obviously this isn't possible as the engine might be in an unstable state and it would be unsafe to continue.

But I figure if the internals of PHP can handle it, would it not be possible to upon fatal errors run a pre-defined script filename (settable via iniset/putenv as well) using a new instance of the engine with the error available (perhaps the backtrace as well) in $_SERVER or wherever? So that you could apply your own error logging and output.

So instead of:
runscript IF fatalerror THEN printfatal END
You would get something like:
runscript IF fatalerror THEN runhandler IF fatalerror THEN printfatal END END

This would be a blessing for both custom debugging functionality, giving clients useful errors and being able to log these actions using custom utilities (most people don't have access or log php errors in the http-log). As in fact, the common fatal errors are that you have called a non-existant function, worked on a bad object or put in a bad character and not the engine going rogue.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-05-17 17:21 UTC] tony2001@php.net
log_errors = On
error_log = <whatever you want>
 [2007-05-17 17:34 UTC] public at syranide dot com
That isn't quite what I meant, as clients will still see a php error, or none at all and you have no means of invoking your own routines.

Being able to output a custom error message or even try to recover from it, log the error using custom utilities and even send a warning by mail would be a major addition to PHP in my opinion for larger systems.

If you feel that this is not a relevant feature then return it to "bogus".
 [2007-05-17 17:47 UTC] tony2001@php.net
>That isn't quite what I meant, as clients will still see a php error

Ever heard of display_errors?

>or none at all and you have no means of invoking your own routines.

Fatal errors are called so because they are fatal.
You can't invoke any routines or send an email, because a fatal error occured.

>log the error using custom utilities 

We do have a log utility which you can set up in the way you want, it's custom enough to fulfill any basic needs.

>If you feel that this is not a relevant feature then return it to
"bogus".

Yeah, I do feel that making fatal errors non-fatal is bogus idea. 
 [2007-05-17 23:45 UTC] stas@php.net
You many see discussion of some ideas that do roughly what you are looking for here:
http://php100.wordpress.com/2007/04/16/graceful-recovery/#comments
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Apr 16 09:01:28 2024 UTC