Php suppress all errors

@print($a);
is equivalent to
if isset($a) echo $a ;

@a++;
is equivalent to
if isset($a) $a++ ;
else $a = 1;

It’s still possible to detect when the @ operator is being used in the error handler in PHP8. Calling error_reporting() will no longer return 0 as documented, but using the @ operator does still change the return value when you call error_reporting().

My PHP error settings are set to use E_ALL, and when I call error_reporting() from the error handler of a non-suppressed error, it returns E_ALL as expected.

I didn’t want to use 4437 in my code in case it changes with different settings or future versions of PHP, so I now use:

function my_error_handler ( $err_no , $err_msg , $filename , $linenum ) if ( error_reporting () != E_ALL ) return false ; // Silenced
>

// .
>
?>

If the code needs to work with all versions of PHP, you could check that error_reporting() doesn’t equal E_ALL or 0.

And, of course, if your error_reporting settings in PHP is something other than E_ALL, you’ll have to change that to whatever setting you do use.

After some time investigating as to why I was still getting errors that were supposed to be suppressed with @ I found the following.

1. If you have set your own default error handler then the error still gets sent to the error handler regardless of the @ sign.

2. As mentioned below the @ suppression only changes the error level for that call. This is not to say that in your error handler you can check the given $errno for a value of 0 as the $errno will still refer to the TYPE(not the error level) of error e.g. E_WARNING or E_ERROR etc

3. The @ only changes the rumtime error reporting level just for that one call to 0. This means inside your custom error handler you can check the current runtime error_reporting level using error_reporting() (note that one must NOT pass any parameter to this function if you want to get the current value) and if its zero then you know that it has been suppressed.
// Custom error handler
function myErrorHandler ( $errno , $errstr , $errfile , $errline )
if ( 0 == error_reporting () ) // Error reporting is currently turned off or suppressed with @
return;
>
// Do your normal custom error reporting here
>
?>

For more info on setting a custom error handler see: http://php.net/manual/en/function.set-error-handler.php
For more info on error_reporting see: http://www.php.net/manual/en/function.error-reporting.php

Be aware that using @ is dog-slow, as PHP incurs overhead to suppressing errors in this way. It’s a trade-off between speed and convenience.

If you use the ErrorException exception to have a unified error management, I’ll advise you to test against error_reporting in the error handler, not in the exception handler as you might encounter some headaches like blank pages as error_reporting might not be transmitted to exception handler.

function exception_error_handler ( $errno , $errstr , $errfile , $errline )
throw new ErrorException ( $errstr , 0 , $errno , $errfile , $errline );
>

function catchException ( $e )
if ( error_reporting () === 0 )
return;
>

function exception_error_handler ( $errno , $errstr , $errfile , $errline )
if ( error_reporting () === 0 )
return;
>

throw new ErrorException ( $errstr , 0 , $errno , $errfile , $errline );
>

function catchException ( $e )
// Do some stuff
>

Источник

How to remove warning and error messages in PHP

Error warnings for PHP are helpful during development, where you can use them for debugging. Showing the same errors and warnings in a production environment could pose a security risk as it could expose sensitive and exploitable information about the system.

Warning and error reporting in PHP are configured via the display_error error_reporting directives. display_error defines if errors are displayed at all, while error_reporting allows you to specify the type or level of errors to show.

Steps to remove error and warning messages in PHP:

$ sudo vi /etc/php/7.4/apache2/php.ini

; This directive controls whether or not and where PHP will output errors, ; notices and warnings too. Error output is very useful during development, but ; it could be very dangerous in production environments. Depending on the code ; which is triggering the error, sensitive information could potentially leak ; out of your application such as database usernames and passwords or worse. ; For production environments, we recommend logging errors rather than ; sending them to STDOUT. ; Possible Values: ; Off = Do not display any errors ; stderr = Display errors to STDERR (affects only CGI/CLI binaries!) ; On or stdout = Display errors to STDOUT ; Default Value: On ; Development Value: On ; Production Value: Off ; http://php.net/display-errors display_errors = On

Set the value to On instead to further tune the types of messages to display using error_reporting directive.

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; Error handling and logging ; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ; This directive informs PHP of which errors, warnings and notices you would like ; it to take action for. The recommended way of setting values for this ; directive is through the use of the error level constants and bitwise ; operators. The error level constants are below here for convenience as well as ; some common settings and their meanings. ; By default, PHP is set to take action on all errors, notices and warnings EXCEPT ; those related to E_NOTICE and E_STRICT, which together cover best practices and ; recommended coding standards in PHP. For performance reasons, this is the ; recommend error reporting setting. Your production server shouldn't be wasting ; resources complaining about best practices and coding standards. That's what ; development servers and development settings are for. ; Note: The php.ini-development file has this setting as E_ALL. This ; means it pretty much reports everything which is exactly what you want during ; development and early testing. ; ; Error Level Constants: ; E_ALL - All errors and warnings (includes E_STRICT as of PHP 5.4.0) ; E_ERROR - fatal run-time errors ; E_RECOVERABLE_ERROR - almost fatal run-time errors ; E_WARNING - run-time warnings (non-fatal errors) ; E_PARSE - compile-time parse errors ; E_NOTICE - run-time notices (these are warnings which often result ; from a bug in your code, but it's possible that it was ; intentional (e.g., using an uninitialized variable and ; relying on the fact it is automatically initialized to an ; empty string) ; E_STRICT - run-time notices, enable to have PHP suggest changes ; to your code which will ensure the best interoperability ; and forward compatibility of your code ; E_CORE_ERROR - fatal errors that occur during PHP's initial startup ; E_CORE_WARNING - warnings (non-fatal errors) that occur during PHP's ; initial startup ; E_COMPILE_ERROR - fatal compile-time errors ; E_COMPILE_WARNING - compile-time warnings (non-fatal errors) ; E_USER_ERROR - user-generated error message ; E_USER_WARNING - user-generated warning message ; E_USER_NOTICE - user-generated notice message ; E_DEPRECATED - warn about code that will not work in future versions ; of PHP ; E_USER_DEPRECATED - user-generated deprecation warnings ; ; Common Values: ; E_ALL (Show all errors, warnings and notices including coding standards.) ; E_ALL & ~E_NOTICE (Show all errors, except for notices) ; E_ALL & ~E_NOTICE & ~E_STRICT (Show all errors, except for notices and coding standards warnings.) ; E_COMPILE_ERROR|E_RECOVERABLE_ERROR|E_ERROR|E_CORE_ERROR (Show only errors) ; Default Value: E_ALL & ~E_NOTICE & ~E_STRICT & ~E_DEPRECATED ; Development Value: E_ALL ; Production Value: E_ALL & ~E_DEPRECATED & ~E_STRICT ; http://php.net/error-reporting error_reporting = E_ALL

error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT

$ sudo systemctl restart apache2

Источник

How to remove warnings in PHP.

In this guide, we will show you how to remove warning messages in PHP.

We will also explain why it is generally a bad idea to hide all warning messages.

Hiding all warning messages is basically the same as turning up the music in your car so that you can’t hear the worrying noise that your engine is making.

Hiding PHP warnings with the error_reporting function.

The error_reporting function allows us to tell PHP which errors to report.

For example, if we want to display all error messages except warnings, we can use the following line of code:

//Report all errors except warnings. error_reporting(E_ALL ^ E_WARNING);

Typically speaking, the error_reporting function should be placed at the top of your code. This is because the function can only control errors that occur in the code below it.

Can I hide PHP notice messages as well?

If you also want to hide notice messages, then you can set the following level in the error_reporting function:

//Only report fatal errors and parse errors. error_reporting(E_ERROR | E_PARSE); //This will usually create a division by 0 //warning message. echo 1 / 0; //This will usually create an array to string //notice message. echo array();

In the code snippet above, we told PHP that it should only report fatal errors (E_ERROR) and parse errors (E_PARSE).

Afterwards, we created two lines of code:

We divided 1 by 0, which would typically result in a “Warning: Division by zero” message.
We then attempted to echo out an array. Under normal circumstances, this would cause the following notice: “Notice: Array to string conversion”

If you run the example above, you will see that the page doesn’t display any notices or warnings. Furthermore, if you check the PHP error log, you will see that they also haven’t been logged.

Stopping warning messages from being displayed.

If you simply want to stop warning messages from being displayed, but not prevent them from being logged, then you can use the following piece of code:

//Tell PHP to log errors ini_set('log_errors', 'On'); //Tell PHP to not display errors ini_set('display_errors', 'Off'); //Set error_reporting to E_ALL ini_set('error_reporting', E_ALL );

Here, we are using PHP’s ini_set function to dynamically modify the settings in our php.ini file:

We set log_errors to On , which means that PHP will log warnings to our error log.
We set display_errors to Off . As a result, PHP will not output errors to the screen.
Finally, we set error_reporting to E_ALL.

Note: If you can access your php.ini file, then you should probably edit these values directly instead of changing them on the fly.

Using the @ character to suppress errors.

In some cases, you might not have control over certain warnings.

For example, a GET request to an external API could fail, resulting in a “failed to open stream” warning. To prevent this from occurring, we could use the @ character like so:

//API URL $url = 'http://example.com/api'; //Attempt to get contents of that URL $result = @file_get_contents($url);

As you can see, we have placed the @ (AT) character next to our function call. This means that if file_get_contents fails, it will not throw an E_WARNING message.

This works because the @ character is an error control operator that tells PHP to ignore any errors.

Note that error suppression should be used sparingly. Abusing this control operator can lead to issues that are difficult to debug.

Why should I not suppress all warning messages?

An E_WARNING message is an error that does not prevent the rest of your PHP script from executing. Although it does not halt the script, it is still an error. It means that something in your code is not working the way that it is supposed to be working.

You should always try to address the issue instead of hiding it. Otherwise, it may lead to other bugs further down the line.

If you sweep these warning messages under the rug, you will be limiting your ability to spot serious problems in your application.

For example, what if your online shop had a “division by one” error that was preventing certain users from adding multiple items to their basket? Perhaps this issue only occurs when the user applies an expired coupon. Or maybe it happens after they reduce the quantity of an item in their basket.

Either way, something bad is happening and you don’t know about it.

You cannot rely on end users to report issues. Many of them will either think that they are using the website incorrectly or they will simply forget about it and move on. Internet users are impatient. They usually won’t take the time to fill out contact forms or attach screenshots.

As a result, this lazy approach of “nuking” all warning messages has caused your online shop to lose out on sales.

Источник

Читайте также: Html text node style