I recently upgraded to PHP 8.1 and did my best to fix instances of where NULL was being passed to built-in functions such as trim() or strtolower(). As expected, I missed some. However, it seems that the exceptions thrown by this in PHP are not E_DEPRECATED. I can't find what type of exception is documented to be thrown exactly. The migration guide just says the below and the comment in the code makes me think it would throw E_DEPRECATED.
Scalar types for built-in functions are nullable by default, this behaviour is deprecated to align with the behaviour of user-defined functions, where scalar types need to be marked as nullable explicitly.
I have error_reporting in my php.ini set to E_ALL & ~E_DEPRECATED & ~E_STRICT and yet I am still getting exceptions thrown. I log the text of the exception in our database and it sure looks like a deprecation message. Does anyone know what type of error is thrown exactly?
I have an error handler defined but am not passing anything in the second parameter for the error levels. Maybe I am misunderstanding how set_error_handler works in conjunction with error_reporting?
Related
I have a PHP REST API endpoint that throws an error:
PHP message: PHP Fatal error: Uncaught Exception: Accessing static property...as non static in...
with the default error_reporting value but returns a correct value if error_reporting is set to 1, which I believe is E_ERROR.
Doesn't error_reporting just control the logging? This seems to control whether the exception is thrown as well, allowing the code to continue as normal.
I come from a Java background, used to using Logback and similar logging frameworks. In these frameworks, the log level refers to a filter for the recipient of the logs, commonly a log file. A log level X means that messages need to be at least level X (or lower than, I forget which) to be logged, but it doesn't affect whether the exception is thrown to begin with.
I had assumed that this was the case with PHP's error_reporting, however, based on the above behavior I am not sure.
I've looked through the PHP docs, but I haven't found a detailed explanationof how error_reporting works
So, my question: What does "reporting" mean here? Does error_reporting control more besides which exceptions/errors are logged?
error_reporting is a bit different with the log level, the argument is a set of toggles for each error type.
For example error_reporting(E_ERROR) only reports errors and error_reporting(E_NOTICE) only reports notices and error_reporting(E_ERROR|E_NOTICE) reports both errors and notices but doesn't report warnings.
FYI the error level of this message "Accessing static property...as non static in..." is E_STRICT in PHP 5 and E_NOTICE in PHP 7 by default.
This is weired because you got an exception, I guess the problem that changes the behaviour of the error is in your error handler.
I (like a lot of others) am seeing Strict Standards errors with PHP 5.4.???.
Strict Standards: Only variables should be passed by reference in /home/xxxxxx/public_html/xxxxxx/init.php on line 64
There must have been a change between 5.3 and 5.4. All the "wisdom" on the Internet seems to be about turning the error messages off. In this case this is a program (1,000's of lines written by someone else) that I am disinclined to try to resolve.
If I turn off the error reporting then the script does not execute.
I am trying to work the issue with the writer of the script.
Is there any other solution? Is there a setting that can be placed in the .htaccess file that will allow "non strict standards"?
You need to go into your php.ini file and assign the following:
error_reporting = E_ALL & ~E_DEPRECATED & ~E_STRICT
This will allow you to show all warnings except deprecated & non-strict standards.
If you want to fix the error rather than ignore it (recomended):
$uri = explode("/",$_SERVER['REQUEST_URI']);
define("INSTALL_URL" , $protocall.$host_name . str_replace("/".array_pop($uri),"/",$_SERVER['REQUEST_URI']));
I managed to run MongoDB on Codeigniter using Alex Bilbie` library. The operations go well (connection, queries etc. ) but sometimes I get these PHP notices:
Message: Mongo::__construct() [mongo.--construct]: localhost:27017: pool get (0x4bfab20)
Filename: libraries/Mongo_db.php
Line Number: 1274
A PHP Error was encountered
Severity: Notice
Message: Mongo::__construct() [mongo.--construct]: localhost:27017: found in pool (0x4bfab20)
Filename: libraries/Mongo_db.php
Is there a way to get rid of these? or maybe hide them..as they don't seem to mess up my pages in another way than splashing into the user's screen.
EDIT
On a few pages though, I use the JQgrid and when the errors show up they mess up my HTTP response and render some messy data.
The specific notice messages here have been removed in the MongoDB PHP driver 1.2.11 or later (see PHP-431). Upgrading your MongoDB driver to the latest should remove the excessive notice logging.
General notes on proper settings for Code Igniter logging in production still apply...
The E_NOTICE level of error reporting is intended to warn you about possible bugs or typos. It is typically only used as a development setting rather than for production messages.
The default error_reporting setting in PHP4 and PHP5 is actually set to ignore these:
E_ALL & ~E_NOTICE
The Code Igniter index.php has an application environment setting which normally shows all errors for development and suppresses error reporting for testing and production. You should set this appropriately:
define('ENVIRONMENT', 'production');
If you actually want to capture these messages for a production environment you should update the production settings in your index.php so that instead of error_reporting(0) you have:
error_reporting() set to appropriate level of detail
display_errors off
log_errors on
error_log path set
For example, in index.php you could have:
case 'production':
error_reporting(E_ALL);
ini_set('display_errors','Off');
ini_set('log_errors','On');
ini_set('error_log','/var/log/php5.log');
break;
That way the messages/notices will still be saved to the error_log if you want to review them, but they will not be shown to the end user.
Off the top of my head, there are a few things you could do. This is not an answer regarding a fix to the MongoDB error you are receveing, but rather regarding some methods in which you could hide the errors.
a) Use the '#' operator to ignore any error outputs from the method being called in which outputs the errors you are receiving. This would result in you renaming the method call to the following #method_outputting_mongodb_error($foo,$bar);.
b) Turn off error reporting in CodeIgniter. This is not the best method as all other errors will not be outputted.
There is a good link here re: how you can turn off error reporting: http://phpdog.blogspot.fr/2012/02/codeigniter-error-reporting-handling.html
As #Stennie mentions this has been fixed in later versions of the driver: https://jira.mongodb.org/browse/PHP-431
Try and upgrade.
Also this only existed on the Windows driver and only start happening after v1.2.1. I know that because the guy who made that JIRA also tried 1.2.1 on my advice and he didn't get those E_NOTICEs. I remember having the conversation that actually triggered that JIRA now :).
Unlike others I don't think you should "hide" these errors with E_ALL & ~E_NOTICE. No one is quite decided on hiding E_NOTICE however the general concensus is that it is not the best thing. Of course you would not want your logs to be filled with all this debug info about the MongoDB extension, instead the MongoDB extension should be silent (as you think it should).
Another reason I would not hide E_NOTICE is because of the php.ini of later versions of PHP:
; error_reporting
; Default Value: E_ALL & ~E_NOTICE
; Development Value: E_ALL | E_STRICT
; Production Value: E_ALL & ~E_DEPRECATED
By default PHP will actually install for Production Value (as it does for me) as such the default for PHP error reporting is:
E_ALL & ~E_DEPRECATED
This is the value I have for error_reporting on both my AWS and my local Ubuntu server 12.04 and I have not changed the values since installing as such the default value I gain from installing PHP from both repo and source is:
error_reporting = E_ALL & ~E_DEPRECATED
So the recommended default setup for production for later PHP versions (and probably future ones) actually shows E_NOTICE, which is useful but not if the logs are being filled with stuff from the Mongo extension.
Edit: Downvoter care to explain? I have basically given the same answer as #Stennie, why the downvote?
I have edited my answer to actually take the conversation in the comments on this answer and #Stennie's answer into consideration so the answer makes more sense now.
I've seemingly tried about every different suggestion provided through a couple hours of Google and stackoverflow searching to no avail, and I cannot seem to suppress a large sum of "Deprecated: Assigning the return value of new by reference is deprecated in " errors presented at the top of my application, as well as Many "Warning: the magic method __get() (and __set()) must have public visibility and cannot be static in . Thus far, I have added the following line and many different variations of it to my php.ini file:
error_reporting = E_ALL & ~E_DEPRECATED
error_reporting = E_ALL ^ E_DEPRECATED
I've also attempted a straight suppression of every single error:
error_reporting = ~E_ALL
To no avail either. I've confirmed that it is correctly reading the php.ini file by adjusting other settings successfully.
I've also applied the error_reporting() function (with all different variations of what's provided above) within my scripts with no more luck. Does the location of the reporting have anything to do with the suppression? I've tried posting it at the top of the first file being loaded, also at the top of a required file that is getting called immediately upon executing the main script, no where does it seem to take it.
Try it with a number: http://www.php.net/manual/en/errorfunc.constants.php
Everything but the two deprecateds would be 8191.
PS. It's possible the app/framework/website you're watching/editing/creating sets the error reporting level to E_ALL. If so, it doesn't matter what you set in php.ini, because it's overridden later.
Since updating my testing server to PHP 5.3.3 (Debian Squeeze) I encountered strange behaviour regarding the error reporting in PHP.
I set error_reporting like this:
error_reporting(E_ALL);
and checked the setting via
echo error_reporting();
which echoes 30719. According to php.net this means "All errors and warnings, as supported, except of level E_STRICT.".
But in the very next line (a class definition abstract class formInputContainer extends formContainer implements formElementValueable { ... }) this results in the message:
Strict (2048): Declaration of formInputContainer::addElement() should be compatible with that of formContainer::addElement()
Why is the E_STRICT message echoed though it's not set? Even changing to E_ALL & ~E_STRICT does not help.
The reason you're seeing them even though they are not set, is that these are thrown at compile time (well, parse time). That means the errors are triggered before your error_reporting() call is made. The real fix is to change the php.ini setting to remove E_STRICT from the definition. To make sure you're editing the correct file, check phpinfo().
If this is a custom error handler (set via set_error_handler()), you'll have to check the current error_reporting level by yourself. A custom error handler gets all error messages:
The manual says:
It is important to remember that the standard PHP error handler is completely bypassed for the error types specified by error_types unless the callback function returns FALSE. error_reporting() settings will have no effect and your error handler will be called regardless - however you are still able to read the current value of error_reporting and act appropriately.