Stop Printing mysql_connect() Errors 1

[Glowball]

I've put the @ symbol before mysql_connect() and that will suppress the PHP errors that get written to the user's browser if there is an issue (like if the password is incorrect, for example).

If the database is having an issue, though, there doesn't seem to be a way around the errors. For exmple, our passwords on the server got corrupt and the @ before the function didn't stop the errors from appearing. It's very frustrating because there doesn't seem to be a way to kill all errors.

Any thoughts are appreciated!

 

[sleipnir214]

In your php.ini, what is the value of display_errors?

Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[Glowball]

Thanks for the quick reply, sleipnir214.

It's set to 1 (ON) and in my script I put this to try to fix it so I don't have to have it reset all the time:

ini_set("display_errors", 0);

Unfortunately I haven't found a way to test this to see if it works if the database is unreachable or having issues. Changing the parameters that go to mysql_connect() aren't an accurate test.

What do you think?

 

[sleipnir214]

Keep in mind that if you are making the change by having your scripts execute ini_set(), every one of your scripts will have to run ini_set(). Each script run will revert to the php.ini setting.

Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[Glowball]

The whole site is on index.php so that's okay. Any ideas about how to trap the error if the database isn't functioning correctly?

 

[sleipnir214]

According to the PHP online manual entry for mysql_connect(), the function will return FALSE if it fails. It should be trivial for a script to compare the value returned from the function to FALSE and react appropriately.

Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[Glowball]

That's the issue -- it doesn't. This function does not react appropriately if there are database issues. This isn't the first time I've seen it. Trying to trap the issue by including an "or die()" clause doesn't work. Putting the @ in front of the function doesn't work. It still spits out the PHP error to the client and doesn't exit properly.

Changing parameters that go to mysql_connect() to make it fail on purpose doesn't replicate the problem accurately. It has to be when the database is down.

Luckily (unfortunately) we just had a different database go down and I got to test it with display_errors set to 0. That worked, and I was able to exit gracefully.

So it looks like this one function just doesn't cooperate.

 

[sleipnir214]

If by trapping the error you mean, "Control PHP's response to the error completely, regardless of the setting of display_errors", then no, you can't trap this kind of error in PHP. On all my production servers, I set display_errors to "off" or 0 -- my code will be reacting to the return from functions.

Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[Glowball]

But shouldn't the @ symbol suppress the errors for that function at that time, regardless of the setting for display_errors?

 

[sleipnir214]

Not necessarily. The "@" error-supression operator has limited use. Some external libraries (like MySQL's communications libraries) seem to be able to bypass it.

Besides, the "@"-operator is evil and should never be used. Too many people use it instead of good code to react to problems.

Just tweak display_errors in your production environment.

Want the best answers? Ask the best questions!

TANSTAAFL!!

 

[Glowball]

Ahhh good info. I thought the @ was all-powerful. Thanks!