'get_class() expects parameter 1 to be object, null given

I got this error in several places of code, when I tried to deploy Symfony 2.8 project on new local machine:

"Warning: get_class() expects parameter 1 to be object, null given"

Haven't find such case on stackoverflow and spent some time to figure out the reason.

php


Solution 1:[1]

As stated elsewhere on this question, in PHP 7.2 get_class manual states:

Note: Explicitly passing NULL as the object is no longer allowed as of PHP 7.2.0. The parameter is still optional and calling get_class() without a parameter from inside a class will work, but passing NULL now emits an E_WARNING notice.

As you found with your own answer.

However you stated:

So downgrading php version to 7.1 solved the problem.

Downgrading PHP is not usually the best or long term way to solve problems*; instead you need to wrap the get_class in a checker function such as is_object, or inversely, is_null:

$baz = new class();
$className = false; // catch all if $baz is not an object
if(is_object($baz)){
    $className = get_class($baz);
}
  • As stated by Nicco Hasse
    If this problem occurs within Symfony code, just changing the Symfony code is not a good idea. And as upgrading Symfony is not an option, as stated in the OPs answer, staying on 7.1 seems to be the best solution

I would say that while it may be fiddly to "fix" Symphony code, I would suggest adding the qualifier is_object to the Symphony code and then updating to the latest Symphony version when it comes out (which I hope would fix this issue).

Solution 2:[2]

The latest versions of Symfony 2.7 and 2.8 should be fully compatible with PHP7.2, however I was still getting this error. Upgrading sonata-project/user-bundle from 3.3 to 3.6 resolved that issue.

Solution 3:[3]

The reason is the difference of PHP versions. This new warning was implemented in PHP 7.2 - https://wiki.php.net/rfc/get_class_disallow_null_parameter

So downgrading php version on my local machine to 7.1 (like it is on production server) solved the problem.

I believe that upgrading vendors might solve it too, but in my case this way is not welcome by customer.

Solution 4:[4]

This exact error has occurred with me for different reason than above. I am using Laravel version 8 and php 7.4 and it happened because I was casting a model property (unsignedSmallInteger) in particular to number instead of integer.

In short, casting to wrong type might cause this issue.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1
Solution 2 David Baucum
Solution 3
Solution 4

Related Questions