tags:

views:

99

answers:

2

Let's say I'm basically inheriting a live site that has a lot of errors in production, I'm basically doing a recode of this entire site which might take a month or so.

There are some cases in which this site was reliant upon external xml file feeds which are no longer there, but the code wasn't properly setup to supply a nice clean error message ( there are various similar circumstances ) - the client is requesting that at least these error messages go away even if for example the content from the xml file isn't published so we wouldn't be seeing php errors and a blank region on the page ( so the rest of the page can look "fine" ).

At one point I have heard of someone using set_error_handler to nullify some cases where it isn't extreme and I had the idea of setting it up to store error messages in a file/log or email them ( and try to not have duplicate error messages ) basically so end users don't have to see those ugly things.

I'm looking for tips from anyone who's actually done this, so thanks in advance.

+1  A: 

On your production server, you should have the following ini settings:

ini_set('error_reporting', E_ALL | E_STRICT);
ini_set('log_errors', true);
ini_set('error_log', '/tmp/php_errors.log'); // or whatever file is appropriate
ini_set('display_errors', false);

By turning off display_errors, your users will never see another error message, but you will be able to see error messages by looking in the log file.

When the re-code is finished, there should be no more errors going into the log file (because you've fixed them all).

Edit: Some developers set error_reporting to E_ALL ^ E_NOTICE as a way of hiding errors. This is bad practice because it hides messages about possible programming errors. You should only use E_ALL ^ E_NOTICE when there are so many Notices coming from legacy code that you are unable to fix them all.

too much php
+2  A: 

When in development, it is good to use

error_reporting(E_ALL);
ini_set('display_errors', 'On');

So you can see errors immediatly : it helps correcting them.


When on the production server, you don't want error displayed, so :

ini_set('display_errors', 'Off');

error_reporting can remain activated : if display_errors is Off, errors won't be displayed anyway -- but you can still have them logged to a file.


BTW, those can be set in the php.ini file, of course :


On the production machine, you might want to use log_errors and error_log, so errors are logged to a file (which means you will be able to know what errors occured -- can be useful, sometimes) ; of course, don't forget to check that file from time to time ;-).


As a sidenote, if you just have a couple functions/methods you don't want to display errors, you could envisage using the @ operator to just mask the errors those might trigger...

... But I strongly advise against it (except in very specific cases) : it make debugging lots harder : errors triggered there are never displayed, not even on your development machine !

In my opinion, it is way better to just disable display_errors on the production machine ; it also means no error will be displayed at all, which is better for users!

Pascal MARTIN