Why use error_reporting with display_errors and display_startup_errors?

Question

I’ve been using only for a long time:

error_reporting(E_ALL|E_STRICT);

To debug scripts (note that I use E_STRICT only to maintain compatibility with older versions of PHP), but I noticed that other people use the:

ini_set('display_errors', 1);

Or when they’re gonna shut down the bugs:

ini_set('display_errors', 0);
ini_set('display_startup_errors', 0);
error_reporting(0);

I know that the display_startup_errors is false (or 0) by default and it refers to displaying errors as extensions that were not loaded, the problem is that as far as testing display_errors=0 and error_reporting(0); has practically the same effect.

My doubts are:

• It is necessary to use the ini_set('display_errors', 0);?

• The error_reporting(0); is no longer enough?

Answer 1

display_errors

The directive display_errors simply is an on-off of error display in script output.

This directive does not change what is saved in PHP logs. It only changes the generated output.

The ideal on production servers is for her to be false in php.ini, not to give details of the problems of your scripts to ordinary users.

Meanwhile, occasionally you need to test a single script, and then use that:

ini_set('display_errors', 1);

The difference in the script to be tested, is that does not affect the rest of the site/ application. And after debugging the code, just remove the line.

Summary:

• In production, you arrow the display_errors for false direct in php.ini, and it doesn’t change that, except occasionally, to thresh a script, and that’s if you can’t test it on a development server.

  Important after solving the problem, remove the exception from PHP.

  If you’re in a situation where you don’t have access to php.ini in production, and display_errors is connected, has two outputs, in this order of preference:

  1. change accommodation, OR

  2. use the ini_set to disable on all pages, or on a include used in all.

• In development: let the display_errors php.ini in true, so you don’t have to do anything else anywhere.

display_startup_errors

Basically, this configuration is similar to display_errors, but refers to errors that occurred during the PHP startup process, not the execution of the script.

Even more than the previous item, it is preferable to be disabled, and only to be connected to debug of something more serious that has not been identified by other means. For normal problems in your script, the display_errors that’s enough.

error_reporting

Here we are talking about another kind of thing. The error_reporting serves for you to define what kind of errors will display and log in.

Normally, in development, the ideal is to leave E_ALL, so you’ll see the mistakes and the warnings about a diversity of things that may give problem in current code and future code.

Perhaps, in production, E_ALL is a bit of an exaggeration, but letting zero might just hide some problem you didn’t notice in the development. Warning about obsolete things may not be important in production, but hiding everything is hardly desirable.

Note that it is important to read the PHP documentation, because amazingly, the E_ALL only really shows all errors in newer versions.

Main options:

E_ALL           Todos os erros e alertas (Cuidado. Veja o E_STRICT)
E_ERROR         Erros fatais em runtime
E_WARNING       Erros não fatais em runtime
E_PARSE         Erros de compilação (antes da execução do código)
E_DEPRECATED    Avisos de coisas obsoletas, que serão retiradas no futuro
E_NOTICE        Avisos que podem ou não ser bugs
E_STRICT        Dá recomendações de melhor interoperabilidade, desde o PHP 5.
                Note que o E_ALL só inclui o E_STRICT do 5.4 em diante

Summary:

• In production, probably a good combination is:

  E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED
  

  note that the & ~ means that we are disabling that option (is a AND binary of a NOT of flag).

• In the development I suggest using the E_ALL | E_STRICT and everything else you’re entitled to.

Answer 2

A complement to the existing answer,

Depending on the environment, error_reporting(); or ini_set('display_errors', ..); can be ignored when invoked at runtime.

To put it more simply, there are hosting servers that don’t allow these settings to be made by PHP or htaccess. Usually in these cases they offer a specific administrative panel to set the settings. Hence, it is common to see many PHP users setting up at runtime and complaining that the script "doesn’t work".

In such cases there is not much to do. One should use the resources of the hosting provider.

A relevant note is that PHP 7 has made several features marked as obsolete DEPRECATED and also modified the level of error messages for certain executions that until then were emitting as E_STRICT.

Example

class Foo
{
    Bar(){}
}

This is not allowed since version 5.4, if I am not mistaken. Since this version, the error has been issued in the level E_STRICT.

To "solve", we hide this error level by the function error_reporting() or ini_set(). However, this is no longer possible in PHP7 as it is issued Fatal Error.

So hide level errors E_STRICT is a choice that should be made with caution. Only apply when necessary. Usually we apply in legacy systems where it is impractical to correct everything in a timely manner.

In the case of the above example, PHP, since vesion 5.4, asks for class methods and properties to have explicit visibility definition.

Example to avoid STRICT (php5.4~5.6) or FATAL ERROR (php7)

class Foo
{
    public Bar(){}
}

Obviously this also affects "violations" that until then were allowed.

class Foo
{
    public static Bar(){}
    public Other(){}
}

/**
Acessando de forma estática um método não estático.
*/
Foo::Other();

This generates an error level STRICT from PHP 5.4. This error, as mentioned above, can be hidden and thus "solved" the problem. We’re actually hiding the dirt under the rug.

In PHP7 this is also no longer of the level STRICT and is issued FATAL ERROR.

The above example with classes is small as there are several changes in PHP7.

The recommendation is always to solve every kind of error at the level E_STRICT and even the simplest of the kind E_NOTICE. Therefore, in the development environment all levels of error must be kept active. And, of course, in the production environment it is advisable to hide the errors of being publicly displayed. The common user does not need to know details of errors because it also implies security failure because it exposes information to malicious people.