Promote mysqli warnings to exceptions

[kocsismate]

It's a nightmare to adapt the tests... So I'll only continue if we make sure that the warnings in question can be promoted to exceptions. :)

[kocsismate]

@nikic could you tell me if it is really ok to continue?

[nikic]

Could you please describe under which conditions this error would occur? From what I gathered, it happens if either a) the connection hasn't been opened yet or b) the connection is already closed. I think in principle that would be fine, as it is consistent with us throwing for closed resources.

One thing I'm wondering about in particular is how that interacts with the "Gone away" condition. Would that also result in an exception on the next interaction? That might be fragile.

[kocsismate]

It happens if either a) the connection hasn't been opened yet or b) the connection is already closed

You are right, this is my understanding (and experience after working on the tests) as well. Additionally, the resource of prepared statements and results should be open when accessing them in order to avoid throwing an exception.

I think in principle that would be fine

Yep, throwing also makes sense for me, mainly I was unsure about the possible BC impact.

[nikic]

I've looked a bit closer at this now, it should be good to go ahead. I've removed two of the conditions in 55618ff, because they cannot occur in practice.

The Couldn't fetch %s error should be changed to something like %s object is already closed, because that's the only condition under which it should occur.

The invalid object or resource %s could be something like %s object is not fully initialized. What that means depends on the object type, e.g. it's a connection that's not connected, or a statement that's not prepared.

Apart from these suggestions, this change should be in line with our exception guidelines.

[kocsismate]

Thank you, Nikita, for having a detailed look! I updated my PR:

• It turned out that the "Failed to fetch ..." warnings were raised from some other places as well (mysqli_poll() and during accessing the properties like $mysqli->affected_rows)
• There is only one test failure in Travis: https://travis-ci.org/php/php-src/jobs/636600526#L1946 which corresponds to https://github.com/php/php-src/pull/5058/files#diff-25af24d4f8a23e3e690fcafaf025cda4 I can't understand why the try-catch block doesn't catch the Error... I feel that it's that situation when you can't see the forest for the trees... :/

[kocsismate]

OMG, I've just noticed that I echoed the exception itself, not just the message... I should have stopped a little bit earlier yesterday... :)

[nikic]

Could you please split off the last commit into a separate PR? It's really a fix for an independent issue, that just becomes more problematic with exceptions. See https://bugs.php.net/bug.php?id=78666 for bug report.