There is no exact answer as it depends on the environment and circumstances.
A simple setup that 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 area for your case.
The parameter error_log
indicates the location where the error messages will be saved.
Some environments may not have a definition in php.ini and this causes Warning error in some versions of PHP. So it’s good dfinir, but it’s not required. When you’re sure the environment already has the configuration, it’s redundant to specify again.
The same goes for the other parameters. If you already have the same value in php.ini, then you don’t need to set it again at runtime.
Why the definition also depends on circumstances?
Let’s take 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 impossible to fix an entire system so we do certain "gambiarras" and settings to give a backward compatibility of PHP to the system.
Taking the example of this answer: /a/106569/4793
From PHP5.4 the following code shows type error STRICT
:
class Foo
{
public Bar(){}
}
To be able to "dribble" these level error messages STRICT
, we can do this:
error_reporting(E_ALL & ~E_STRICT);
This is enough to provide a backward compatibility for this particular case.
Obviously, one must correct all kinds of errors one finds, from the simplest as level errors NOTICE
.
Be aware that the Runtime settings (at runtime) depend on the environment. There are hosting providers who impose restrictions or simply block the use or overwrite the parameters. More details on this answer: /a/106569/4793
Error inhibitor
In many scripts we will find the use of @
at the beginning of a function call.
The symbol @
, in such cases, acts as an error inhibitor. That is, possible error messages or warnings that a dispatch function, is hidden.
It usually applies to cover problems in legacy systems (gambiarras) or it also applies in legitimate cases as different PHP functions that trigger errors inexpensively, without a standard behavior. Ask that question: Why do they say using @arroba to suppress errors is a bad practice?
PHP in CGI mode
There are cases where one cannot control certain errors to appear on the user screen. Usually this happens most when PHP runs as CGI.
In CGI mode, for a fatal error, when display_errors is disabled, it will emit http status 500 "Internal server error".
To test know more details, see this link: /questions/115127/diretiva-display-errors-off-causa-500-internal-error-server
Exceptions
To talk about exceptions would make this response too extensive. There are several links on the subject.
What are Exceptions?
What are the native PHP Exceptions?
Capture errors and PHP Exceptions
I want to use php exceptions to ignore an error that ends up terminating the script
When to use Exceptions in PHP?
Which Exception should I release according to each situation?
Finally, it is really extensive. In a simple search you will find dozens of cases.
The safest way is to make no mistakes :P. Display errors on the screen no problem at all as long as it is in the development environment, in production you can choose to record in text file or database, for something very critical an sms/email.
– rray
@rray but by the question, he wants to get kkk errors :) - I would say that a safe way is to make the error directly in the source, then it is quite safe that you will get an error. Vinicius, joking aside, the PHP Log is the right place to see the errors of your application. And this usually already works.
– Bacco
@Bacco I noticed the paradox haha :D, I would get success, money and health.
– rray
Here’s something that can help you configure the application: http://answall.com/questions/106562/por-que-usar-error-reporting-com-display-errors-e-display-startup-errors
– Bacco
I give the tip to use Try Catch and customize your error messages, which will be presented to the user, in a class.
– Diego Dias
@Diego Dias some tip on how to do this?
– user45722
Fortunately, when we use a framework (a good one, of course), we don’t have to worry about that ;)
– Wallace Maxters