Question

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.

Answer 1

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 :

• error_reporting
• display_errors

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!