php - Turn off or handle errors within a production environment?

Question

After having an argument with my team because we all have different views on this sort of situation.. When is it actually acceptable to turn off PHP error messages, or to suppress some functions which are throwing warnings, notices for whatever reason..

I understand everyone says that you should turn off error_reporting within a production environment, but that might cause some complications which will not be picked up.. So nothing will get fixed, furthermore. PHP comes with many different methods to control error messages.. For example:

$Var = "Variable Is Set";

if (@$Var){ echo $Var; }

Over:

if (isset($Var)){ echo $Var; }

Because we have a set variable, this will sucessfully echo.. Whereas if we didn't have a set variable, this would throw a notice.. So Which one to use? The isset or error suppression?

And within a production environment, which one would be more acceptable to use?

error_reporting(0);

The above will turn off all types of PHP error reporting, giving no error messages even if something is encountered. So in some cases this could lead to broken code that stops working for an unknown reason, due to the message being destroyed

or:

set_error_handler("");

The above enables a custom error handler, which can be used to gracefully show a error to the user, and enable administration to log the detailed warning.. But then again, the error_handler to my knowledge will not be called when a fatal error is triggered?

So My overall question?

Handle errors in production environment or just turn them off in general? This boils down to best practices and preferences I guess.. But it's something that is puzzling me and my team to the point of disagreements.

Answer 1

You never simply turn off error reporting entirely. You do turn off error display. Directly dumping errors to the screen is necessary during development (unless you have other methods which throw all errors in your face), in production you want the same error reporting but instead of it outputting visible errors, you want it to only log them. This can all be done using PHP's error reporting configuration settings.

If you want special custom error handling/logging, use a custom error handler.

As for @, you never write your application in a way that it produces actual errors on whose behavior you rely. You write everything in a way that does not trigger errors. You only use @ when there's no way to avoid a possible error because you cannot write it any other way, and you expect an error and are handling it; then all you do it to suppress the inevitable error message.