What is the safest way to get errors in PHP?

Asked

Viewed 358 times

1

There are several methods to get the errors in PHP, but I’ve seen many people saying that it is not safe I displayed the default PHP error on the screen since it makes it easier for them to have server information.

I would like to know which is the safest method without problems?

  • 1

    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.

  • 1

    @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 I noticed the paradox haha :D, I would get success, money and health.

  • 3

    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

  • 1

    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 some tip on how to do this?

  • Fortunately, when we use a framework (a good one, of course), we don’t have to worry about that ;)

Show 2 more comments

1 answer

2


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.

  • Is there any way in the production environment, when there is an error I warn myself that an error occurred and I should look at the log file? You also think I should implement that in my question?

  • 1

    There are ways to capture even fatal error, even when issued by php-cgi. But it is better to ask a new question because it is too long.

Browser other questions tagged

You are not signed in. Login or sign up in order to post.