Why use error_reporting with display_errors and display_startup_errors?

display_errors

The display_errors policy is simply a power-off view of the errors in the script output.

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

The ideal thing about production servers is that it is false in php.ini, not to give details of the problems of your scripts to ordinary users.

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

ini_set('display_errors', 1);

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

Summary:

• In production, you'll see display_errors for false direct in php.ini, and does not change this, unless occasionally, to debug a script, and this if it can not test on a development server.

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

  If you are in a situation where you do not have access to php.ini in production, and display_errors is connected, has two outputs, in this order of preference:

• Switch hosting, OR

• Use ini_set to disable on all pages, or an include used on all pages.

• In development: leave display_errors of php .ini to true, so you do not have to do anything else anywhere.

display_startup_errors

Basically, this setting is similar to display_errors , but if refers to the errors that occurred during the PHP initialization process, rather than script execution.

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

error_reporting

Here we are talking about another type of thing. error_reporting is for you to define what kind of errors will display and logar.

Normally, in development, the ideal is to leave E_ALL , so you will see the errors and the warnings about a diversity of things that can give problem in the current code and future code. >

Maybe, in production, E_ALL is a bit of an exaggeration, but leaving zero can simply hide some problem you did not notice in 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, as incredible as it may seem, E_ALL only really shows all the errors in the 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 & ~ means that we are deactivating that option (it is AND binary of a NOT of flag ).

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

A complement to the existing response,

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

Put simply, there are hosting servers that do not allow these settings to be made by PHP or htaccess. Usually in these cases they provide a specific administrative panel to set the settings. So it's common to see many PHP users setting up at runtime and complaining that the script "does not work."

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

A relevant note is that PHP 7 has rendered many features marked as DEPRECATED obsolete and also modified the level of error messages for certain executions that were previously 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 at the E_STRICT level.

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

Therefore, hiding errors from the E_STRICT level is a choice that should be made with caution. Only apply when needed. We usually apply in legacy systems where it is not feasible to fix everything in a timely manner.

In the case of the above example, PHP, since version 5.4, asks that the methods and properties of classes have an explicit definition of visibility.

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

class Foo
{
    public Bar(){}
}

Obviously this also affects "violations" that were previously allowed.

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

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

This generates a STRICT error starting with PHP 5.4. This error, as mentioned above, can be hidden and thus "solve" the problem. We're actually hiding the dirt under the rug.

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

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

The recommendation is always to solve all types of errors at E_STRICT level and even the simplest type E_NOTICE . Therefore, in the development environment all levels of error must be kept active. And obviously, in the production environment it is advisable to hide the errors from being publicly displayed. The average user does not need to know the details of errors, because this also implies a security breach because it exposes information to malicious people.