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

Question

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.

Answer 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).

Answer 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.

Answer 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.

Answer 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.