The Developer Day | Staying Curious

Archive for October 2007

Oct/07

12

PHP Fatal Errors Handling Continued

In my previous post I wrote about few ideas how to capture PHP fatal errors. After some more research I found a few more elegant solutions.

You can wrap all your site with ob_start which accepts a call back function as a parameter which it calls when the content is flushed to the browser. You can use that call back function to preg match for fatal errors.

Another solution is the one I like the most. In my previous post I wrote about a possibility to examine the PHP errors log. Well I found that there are log watch tools to do that easily.

With something like this:

watchfor /(PHP.*error:.*?)$/i
mail addresses=root
threshold=on
threshold track_by=$1,type=limit,count=1,seconds=10

# swatch –daemon -c /root/php_fatal.conf –tail-file=/var/log/apache2/error.log

You can easily track php errors and send them to yourself over the email. And the most exciting detail about this tool is that it won’t spam you with thousands of emails with the same error.

, , Hide

Oct/07

11

PHP Fatal Errors Handling

Did you know that PHP custom made error handlers cannot handle Fatal errors or Parse errors. Those are the errors you would like to watch out for most! It’s not some warning or a notice that pops out and makes your visitor scratch his head. It’s an error that makes your visitor leave and sometimes never come back.

So now that we know that those errors are important to catch and there is no easy way to do it what should we do? Well actually there are some ways around to capture those kind of errors.

First way is kind of extreme, crazy and fun.. In php.ini you can find few options:
; String to output before an error message.
;error_prepend_string = "html code"
; String to output after an error message.
;error_append_string = "html code"

You could execute a simple JavaScript that would extract the fatal error from the document using regular expressions and innerHTML and send them to yourself using AJAX. and you could also display a very friendly message to the visitor by replacing the whole content of the site. The problem with this solution besides the fact that it’s fun is that it is ugly, might not work with every possible browser (hardly), and it requires you to setup a handler file that will accept those errors and send them to you. So you would have to do this on every single domain you have.

Other idea is to make use of a php.ini option error_log = filename. You can log all your php errors to a file. And you can write a cron script that would keep an eye on your file and watch for fatal errors. If it detects one it could easily report about it by sending an email or sending an SMS to your boss that he is losing customers! The cron script could also just empty the file when it gets too big.

I have read some rumors that fatal error handling will be available in PHP6 so there might one day be a proper way to do this. Though it may be that there are other existing solutions.

, , Hide

Find it!

Theme Design by devolux.org