There is no exact answer as it depends on the environment and circumstances.

A simple configuration I recommend is

Development Environment

<?php
date_default_timezone_set('Asia/Tokyo');

ini_set('error_reporting', E_ALL);
ini_set('log_errors', true);
ini_set('html_errors', false);
ini_set('display_errors', true);
ini_set('error_log', dirname(__FILE__).DIRECTORY_SEPARATOR.'logs'.DS.'php_errors-'.date('Ym').'.log');

Production environment

<?php
date_default_timezone_set('Asia/Tokyo');

ini_set('error_reporting', E_ALL);
ini_set('log_errors', true);
ini_set('html_errors', false);
ini_set('display_errors', false);
ini_set('error_log', dirname(__FILE__).DIRECTORY_SEPARATOR.'logs'.DS.'php_errors-'.date('Ym').'.log');

Obviously, date_default_timezone_set() , defines the appropriate zone for you.

The error_log parameter indicates where the error messages will be saved.

Some environments may not have a definition in php.ini and this causes a warning error in some versions of PHP. So it's good to say, but it's not mandatory. When you are sure that the environment already has the configuration, it is redundant to specify again.

The same goes for the other parameters. If you already have the same value in php.ini then you do not have to set it again at runtime.

Why does the definition also depend on circumstances?

Let's look at an example from the real world. You have a legacy system, built in 2003, which used scripts from that time and various adaptations to date. When running in an environment where the PHP version has incompatibilities, in most cases it is unfeasible to fix an entire system so we make certain "hints" and settings to give PHP backwards compatibility to the system.

Taking the example of this answer: link

From PHP5.4 the following code displays an error of type STRICT :

class Foo
{
    public Bar(){}
}

To be able to "dribble" these error messages from level STRICT , we can do this:

error_reporting(E_ALL & ~E_STRICT);

That's enough to provide backward compatibility for that particular case.

Obviously, you should correct all types of errors you find, from the simplest as% level errors.

Be aware that runtime settings (run-time) depend on the environment. There are hosting providers that impose restrictions or simply block usage or override parameters. More details on this answer: link

Error inhibitor

In many scripts we will find the use of NOTICE at the beginning of the function call.

The @ symbol, in these cases, acts as an error inhibitor. That is, possible error messages or warnings that a function would dispatch is hidden.

Usually applies to cover problems in legacy systems (gambiarras) or also applies in legitimate cases as functions other than PHP that trigger inexperienced errors without a default behavior. Please see this question: #

PHP in CGI mode

There are cases where you can not control certain errors that appear on the user's screen. Usually this happens more when PHP runs as CGI.

In CGI mode, for a fatal error, when display_errors is disabled, it will issue status "500 internal server error."

To test for more details, see this link: link

Exceptions

To talk about exceptions would make this answer very extensive. There are several links on the subject.

What are Exceptions?

What are the native Exceptions of PHP?

Capturing PHP errors and Exceptions

I want to use exceptions from php to ignore an error that ends up terminating the script

When to use Exceptions in PHP?

Which exception should I post according to each situation?

Finally, it's really long. In a simple search you will find dozens of cases.