I'm just learning about exceptions and the Exception class, so I decided to give this a go;

The problem is the @ doesn't seem to be suppressing the error from calling a new mysqli object...

Don't use error suppression (@). It only slows your script. Instead, use error_reporting to show or hide the errors (error_reporting(0) in a live environment, error_reporting(E_ALL) when testing).

mysqli::__construct([...]) returns false if a connection couldn't be established, so there's no need for error suppression there (it doesn't generate a notice/error/warning). Instead, try:

__________________

Testing it just now, contrary to the manual the __construct method doesn't seem to return false on connect failure; it instead returns an object of type mysqli along with the warning therefore use mysqli_connect_errno()

and xenon is correct error suppression can have a speed impact on your script, so use error_reporting(0); to hide all warnings/errors/notices etc etc and use your own error handling stuff (for example exceptions)

__________________
mysql> SELECT * FROM `users` WHERE `users`.`clue` > 0;
Empty set (0.00 sec)

Okay, you both seemed to miss the question, but thank you for trying. :)

I'm not worried about the speed impact of using @, because I'm learning about using the Exception class, and in particular the try {} catch {} and throw expressions. I'm also aware of mysqli_connect_error(), errno(), and die() the problem is I don't want to use those just yet. I want the throw new exception to handle the error, without turning off all error reporting on my test server.

@ isn't working anyways, it's not suppressing the error. Neither is error_reporting(0), it's still pumping out Connect failed: Unknown MySQL server host 'DB_SERVE' (11004). The mispelled CONST is on purpose, I'm trying to cause the error in this case.

If the code is precisely as you posted, the @ should suppress any error. If you're still getting the error message then show us a full copy/paste script which doesn't work for you so that we can try it.

The following file outputs (for me) the expected output (error successfully suppressed):

Doh MySQLi Exception: Access denied for user 'root'@'localhost' (using password: YES)

I believe that message is what the mysqli object is printing from its internal error reporting system so therefore it wont get caught by error_reporting(0) or the @ operator.

i think should shut it up

__________________
mysql> SELECT * FROM `users` WHERE `users`.`clue` > 0;
Empty set (0.00 sec)

Salathe: The code is exactly as posted, minus all the other methods and properties in the class, it would look pretty much the same as yours (with the exception being that my constants are defined outside of the class in a seperate config file, thus the lack of self::)

sketch: I'll try that when I get home, that sounds like it could/should help. The wierd thing I'm curious about is this snippet from the manual on mysqli_report;

...seems to imply that even with error reporting on, the error shouldn't pop up unless you explicitly check mysql_connect_errno(), but that's definitely not the case.

I'll update you all when I get home. Thanks again,
-m

I think the manual is a little lacking in areas, it even says that the constructor for mysqli returns FALSE on connect fail, but a constructor can't return values.

taken from "http://uk.php.net/manual/en/mysqli.connect.php"

__________________
mysql> SELECT * FROM `users` WHERE `users`.`clue` > 0;
Empty set (0.00 sec)

Hahah, as usual the mistake is a silly one.

No exception was being thrown because I was checking if $this->mysqli was an object, which it was, error or not. Using mysqli_connect_error() (or as Salathe did, mysqli_connect_errno()) got it to work.

As a sidenote, mysqli_report() doesn't suppress the PHP notice itself, it just means mysqli_connect_error() doesn't get any information to return to you. So I either have to use @ or error_reporting(0) to test my exception.

Oh and apparently the code wasn't *exactly* as posted, but I won't go into further detail now that it's fixed. Lets just chock it up to early morning coding should not happen in my house. Thank you for your time, I'm here all week.
-m

Good to see you're happy delayedinsanity

sketchMedia, the manual isn't very clear I must admit! However, it is simply not possible to assign a value of FALSE to a variable when using $var = new Something which is why an empty object is returned on error and you have to check connect_errno/error to see if something went all wonky.

Yep seems the person who wrote that document either misunderstands how the new keyword works or its been copied from the procedural version (which im supposing must have been written first) and they havent changed that, very confusing for beginners and advanced users alike, i think most of the PHP documentation needs an overhaul anyway.

__________________
mysql> SELECT * FROM `users` WHERE `users`.`clue` > 0;
Empty set (0.00 sec)

actually when that is active, errors that the object encounters get passed through an exception called 'mysqli_sql_exception' therefore doesnt go through the normal PHP error reporting; resulting in both '@' and 'error_reporting(0)' failing.

Glad your all sorted though.

__________________
mysql> SELECT * FROM `users` WHERE `users`.`clue` > 0;
Empty set (0.00 sec)

actually when that is active, errors that the object encounters get passed through an exception called 'mysqli_sql_exception' therefore doesnt go through the normal PHP error reporting; resulting in both '@' and 'error_reporting(0)' failing to catch its messages.

Also as an example, the code snippet posted by salathe, when run with mysqli_report(MYSQLI_REPORT_OFF) set, the message generated is:

which is the exception message set in the catch statement however if its set to on (MYSQLI_REPORT_ALL):

so you see, with it ON the 'mysqli_sql_exception' overrides the exception being thrown in the class because it is raised inside the mysqli object itself.

Glad your all sorted though.

__________________
mysql> SELECT * FROM `users` WHERE `users`.`clue` > 0;
Empty set (0.00 sec)