Whatever error is thrown is controlled by $mysqli->report_mode with option MYSQLI_REPORT_STRICT, you can change that property to not throw exceptions. However, I'd strongly advice to handle exceptions instead of disabling them.

I don't think it makes sense for this function to throw exceptions, because it is usually used to check if a reconnection to the database is needed and it is therefore expected to fail some of the times. The fact that since PHP 8.1 it throws an exception makes all examples in the documentation non-working with the default mysqli reporting options.

@TheNewHEROBRINEX
What is your MySQL version?

Yeah, I guess it makes sense, but I wonder if it's even possible. I will have to look at it more closely. I am not very familiar with this method or how it should actually work.
Regardless, the examples in documentation don't look very helpful at all.

@TheNewHEROBRINEX What is your MySQL version?

/usr/sbin/mysqld Ver 8.0.33-0ubuntu0.23.04.4 for Linux on x86_64 ((Ubuntu))

Thanks for the MySQL version info.
I was able to reproduce it in my environment too.

I've got it down to the point where the exception message is from mysqlnd, not mysqli, but I don't see much difference between 8.1 and 7.4 in the code around it.

It is not yet possible to determine which ext is the cause, as it is quite possible that mysqli is not catching the exception, etc., but I will continue to investigate.

If anything turns up, I'll comment again.

It is a simply problem with the reporting options only.

I can fix it so that no exceptions are thrown.
However, we need to discuss whether this change is a "bug fix" or a "feature change".

It is a simply problem with the reporting options only.

I can fix it so that no exceptions are thrown. However, we need to discuss whether this change is a "bug fix" or a "feature change".

What do you intend to do? Make $mysqli->ping() behave like mysqli reporting is set MYSQLI_REPORT_OFF, regardless of its current value?

Yes, that is exactly right.

Yes, that is exactly right.

That would be acceptable for me but I think the best thing to do would be to exempt $mysqli->ping() from throwing exceptions only if the error is that the connection has been broken but to make it still throw exceptions for other errors.
In the end its new behaviour should become:

• Case 1: the server is alive and responds to the ping -> return true
• Case 2: the connection is broken -> return false
• Case 3: other error -> throw exception

But there is a problem with this: the first time $mysqli->ping() fails, the error is erroneously reported as "Malformed packet" while it doesn't make sense since no packet has been actually received from the server since the connection is broken. If you try to ping the server from the second time on the correct error ("MySQL server has gone away") will be reported.

I think the problem is that mysqlnd_read_packet_header_and_body correctly sets that the server is gone

I think it can be done, but if libmysqlclient has a similar structure, I think that modifying only mysqlnd will cause another problem.

We might try with libmysqlclient to see if we get the same result.

(I haven't used libmysqlclient so it may take some time to verify.)

Don't worry about libmysqliclient as we are no longer allowing it in mysqli. We can deviate from what that library does now.

@kamil-tekiela

Thanks for your useful information!

I'll try to see if I can fix this problem by modifying mysqlnd.

On a side note, this document may be out of date.

https://www.php.net/manual/en/mysqlinfo.library.choosing.php

I think the best thing to do would be to exempt $mysqli->ping() from throwing exceptions only if the error is that the connection has been broken but to make it still throw exceptions for other errors.

I think I got the solution.

#11912

Changes to mysqli::ping are no longer made.
See the pull request conversation for more details.

Changes to mysqli::ping are no longer made. See the pull request conversation for more details.

I have read the conversation, thank you for your time anyway. I appreciated that.