Re: [PHP] trapping fatal errors...?
On Mon, June 12, 2006 5:00 pm, Christopher J. Bottaro wrote: Hello, How can I trap a fatal error (like calling a non existant method, requiring a non existant file, etc) and go to a user defined error handler? I tried set_error_handler(), but it seems to skip over the errors I care about. I don't think you CAN... The closest you could come, after all the set_error_handler and php.ini settings to log and not display etc, would, maybe, be to wrap everything in an ob_start() and search output for ERROR: -- which really sucks, but my boss does it that way... I think, though, that a syntax error would still get triggered before the ob_start() every had a chance, unless you ALSO wrap it all up in an include() somewhere outside the whole app... This gets pretty ugly, pretty fast, but I suppose as a last-ditch effort on top of all the file_exists() etc would be... okay. There is a certain point where the real problem is insufficient testing, though, and I suspect that is where you'd have to be for the ob_start() hack to be a win... -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] trapping fatal errors...?
Hello, How can I trap a fatal error (like calling a non existant method, requiring a non existant file, etc) and go to a user defined error handler? I tried set_error_handler(), but it seems to skip over the errors I care about. Thanks for the help. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Trapping Fatal Errors
Has anyone come up with a way to trap and log fatal PHP errors? I understand how to implement and use a custom error handler for all other error conditions, but there doesn't appear to be any way to log fatal errors (such as a parse error or errors resulting from declaring the same function name multiple times). I was only able to unearth one thread on this list pertaining to this topic and the question never seemed to get answered. If you're interested an archive of that thread is located at: http://marc.theaimsgroup.com/?l=php-generalm=98803976202673w=2 Well... Neither of these solutions is practical, much less elegant, but... I *THINK* that if you wrapped everything in an http://php.net/eval you'd be able to stick an @ in front of it and suppress parse errors... But don't quote me on that... Another option would be to write a PHP page that fetched (using fopen or file) the PHP page you really wanted, and then parsed the results looking for a PHP parse error message, and then either sending the results on out or, err, doing whatever it is you want done. Your final option, of course, is to Use the source, Luke and either (A) alter it to actually allow a higher level of error_reporting that suppresses even parse errors, or (B) whip up a try/catch mechanism to donate back to PHP-Dev in your copious spare time. Yeah, right :-) -- WARNING [EMAIL PROTECTED] address is an endangered species -- Use [EMAIL PROTECTED] Wanna help me out? Like Music? Buy a CD: http://l-i-e.com/artists.htm Volunteer a little time: http://chatmusic.com/volunteer.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
