Apparently, you are confusing new mysqli() with mysqli_connect().

Definitely using the object.
But we are trying to use the mysqli object inside an exception block.  Seems to be some scope issues.

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.

This should probably be reclassified as a Doc bug, because the original code is lifted verbatim from Example 1 of mysql_connect_errno.

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:"?

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.

Thanks for the explanations.  The answer for us is to use the exception's getMessage().

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.