php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #80529 $mysqli->connect_errno may not work
Submitted: 2020-12-17 18:18 UTC Modified: 2020-12-18 17:53 UTC
From: bugs dot php dot net at latter dot org Assigned: cmb (profile)
Status: Not a bug Package: MySQLi related
PHP Version: Irrelevant OS:
Private report: No CVE-ID: None
 [2020-12-17 18:18 UTC] bugs dot php dot net at latter dot org
Description:
------------
---
From manual page: https://php.net/mysqli.construct
---

This example code is given (as below) but if mysqli() returns false (as it will if for example the specified database does not exist) then $mysqli->connect_errno will generate a PHP warning of "Trying to get property 'connect_errno' of non-object".

$mysqli = @new mysqli('localhost', 'fake_user', 'my_password', 'my_db');

if ($mysqli->connect_errno) {
    die('Connect Error: ' . $mysqli->connect_errno);
}



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2020-12-17 18:39 UTC] cmb@php.net
-Status: Open +Status: Not a bug -Assigned To: +Assigned To: cmb
 [2020-12-17 18:39 UTC] cmb@php.net
Apparently, you are confusing new mysqli() with mysqli_connect().
 [2020-12-17 19:20 UTC] bugs dot php dot net at latter dot org
Definitely using the object.
But we are trying to use the mysqli object inside an exception block.  Seems to be some scope issues.
 [2020-12-17 19:42 UTC] requinix@php.net
try {
    $mysqli = new mysqli('localhost', 'fake_user', 'my_password', 'my_db');
} catch (\Throwable $t) {
    echo $mysqli->connect_errno;
}

It's not a scope problem. It's a "if there was an exception thrown before/during the 'new mysqli' then the $mysqli variable will not be assigned" problem.
 [2020-12-17 23:58 UTC] a at b dot c dot de
This should probably be reclassified as a Doc bug, because the original code is lifted verbatim from Example 1 of mysql_connect_errno.
 [2020-12-18 00:09 UTC] a at b dot c dot de
Ah, got it; mysqli_connect may return false, "new mysqli" always returns an object even if the connection fails.

No, wait:
"Returns an object which represents the connection to a MySQL Server, or false on failure." Does this apply to both forms or only to mysqli_connect?

Because further down it says "OO syntax only: If a connection fails an object is still returned. To check if the connection failed then use either the mysqli_connect_error() function or the mysqli->connect_error property as in the preceding examples."

Or are there conditions under which a failed connection returns false and other conditions under which it returns a failed-connection object? Should the Note be moved up to the Return value, and the existing content in the return value be prefixed with "Procedural only:"?
 [2020-12-18 00:32 UTC] requinix@php.net
The original code in the bug report is fine, but it's not the code you were using and it won't create an undefined property warning you mentioned.

Procedural form is a regular function call: returns an object if successful, false if not.
OOP form is a regular class instantiation: guaranteed to return an object... as long as the construction completes and no exception is thrown.

In your real code, apparently an exception is being thrown which means *nothing* is returned - the construction didn't complete. And nothing returned means no $mysqli variable. If you want to check for a connection error in a catch{} then, lacking an object, you need to use mysqli_connect_errno().

> are there conditions under which a failed connection returns false and other
> conditions under which it returns a failed-connection object?

"new mysqli(...)" will never return false. That doesn't mean it will always return, but when it does, it will give you an object.

> Should the Note be moved up to the Return value, and the existing content in
> the return value be prefixed with "Procedural only:"?

You're touching on something that isn't just about this page but about all places where there are OOP and procedural syntaxes.
- The possibility of returning false should be covered in the function declaration at the top of the page, in that gives a return type of "<class>|false"
- "new <class>(...)" invokes __construct, whose declaration should not show any return type at all (because that's how constructors are), and the reader should already be aware of how object instantiation works

Any commentary about return values only ever applies to the procedural form because that's the only place a return value makes sense to talk about.
 [2020-12-18 17:53 UTC] bugs dot php dot net at latter dot org
Thanks for the explanations.  The answer for us is to use the exception's getMessage().
 [2020-12-19 02:13 UTC] a at b dot c dot de
Makes sense. I think one of the things that got me confused was:

try {
    $mysqli = new mysqli('localhost', 'fake_user', 'my_password', 'my_db');
} catch (\Throwable $t) {
    echo $mysqli->connect_errno;
}

If the constructor throws the assignment doesn't happen and there's still the same error. As bugs clarified, $t->getMessage() ought to be used in the catch.

_And then_ look at connect_error to see if the DBMS refused the connection. Or convert errors to exceptions, and try looking at connect_error.
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Sat Jan 16 03:01:24 2021 UTC