Page 2 of 3
Posted: Sat Aug 26, 2006 11:02 am
by RobertGonzalez
d11wtq wrote:AKA Panama Jack wrote:You definately need to use it with a query method. You are not just checking to see if the connection is alive you are checking to see if the query actually PROCESSED. If you have a malformed query this check can return information about the query and what was wrong with it.
So why do you need error surpression again? Can't you just check if mysql_query returns true or false? Like I say, it doesn't display errors with the query you run, it returns a boolean false. You need mysql_error for that. This is why so many newbies get confused with their code not working... mysql_query doesn't look like anything went wrong since it doesn't display errors.
According to the manual...
For SELECT, SHOW, DESCRIBE or EXPLAIN statements, mysql_query() returns a resource on success, or FALSE on error.
For other type of SQL statements, UPDATE, DELETE, DROP, etc, mysql_query() returns TRUE on success or FALSE on error.
...
mysql_query() will also fail and return FALSE if the user does not have permission to access the table(s) referenced by the query.
So, to help out newbies, where in this is there an error returned by the function? I am a little curious also.
Posted: Sat Aug 26, 2006 11:19 am
by Oren
Everah, check the manual again, right above the part you quoted it's written:
link_identifier
The MySQL connection. If the link identifier is not specified, the last link opened by mysql_connect() is assumed. If no such link is found, it will try to create one as if mysql_connect() was called with no arguments. If by chance no connection is found or established, an E_WARNING level warning is generated.
Using '@' you can suppress this
E_WARNING message.
Posted: Sat Aug 26, 2006 11:24 am
by feyd
How about catching the error instead of hiding it away?
set_error_handler().
Posted: Sat Aug 26, 2006 11:37 am
by RobertGonzalez
Thanks Oren, I looked right over that.
Posted: Sat Aug 26, 2006 11:40 am
by Ollie Saunders
Panam wrote:If you do not use the @ to suppress the error message then the page will break in a horrible fashion and look like crap.
- set_error_handler() can be used to make errors tidier. Damn feyd got there first
- You want to be notified of all errors that happen during development and the uglyness doesn't matter
- An easier way of disabling errors for production is ini_set('display_errors', 'Off');
All the code you posted, connecting or querying a db and then doing checks after is fine but error supression is in no way necessary.
Everah wrote:Error suppression slows down your apps.
Right
Everah wrote:I am of the opinion that you can successfully manage potential errors through code rather than relying on hushing them up. I am not a fan of a band-aid approach.
Right
Panam wrote:You definately need to use it with a query method. You are not just checking to see if the connection is alive you are checking to see if the query actually PROCESSED. If you have a malformed query this check can return information about the query and what was wrong with it.
You need the checks sure, but you don't need the error supression. Name one instance where you do.
Panam wrote:I think the debate is still open on if error suppression slows down PHP.
Nope. PHP devs
admitted it was slow.
Panam wrote:I personally don't see it as a band-aid but another tool for programmers to allow them far more control over how PHP reacts to different situations.
What control are you getting that you couldn't get with any of the other methods?
Posted: Sat Aug 26, 2006 12:04 pm
by Chris Corbyn
Everah wrote:Thanks Oren, I looked right over that.
It has nothing to do with mysql_query though....
EDIT | By that I mean an isAlive() method for the connection will mean you don't need error surpression
Posted: Sat Aug 26, 2006 12:35 pm
by RobertGonzalez
d11wtq wrote:It has nothing to do with mysql_query though....
It kinda does. If the link identifier is not found or has issues, this function will return an E_WARNING. I personally would not use error supression throughout a script if I was handling the code procedurally. Locked in a nice DB abstraction, then yeah, but not running it through the entire script line by line for each manual query I run procedurally.
Posted: Sat Aug 26, 2006 2:23 pm
by Benjamin
Umm, display errors shouldn't be turned on, on a production server anyway.
Posted: Sat Aug 26, 2006 2:34 pm
by Oren
astions wrote:Umm, display errors shouldn't be turned on, on a production server anyway.
Not really. You got confused, I believe, with development server - there you should have error reporting set to all, and display errors turned on.
On a production server, turn display errors off
Edit: Now I see that's what you said yourself, I just got you wrong... Sorry

Posted: Sat Aug 26, 2006 2:39 pm
by feyd
If you have an error handler set it doesn't matter if display_errors is on or not or what level error_reporting is (including zero) you'll get information on errors you registered to receive that happen throughout the script. .. provided you don't have any parse errors. I would hope you wouldn't have parse errors in a production environment though...

Posted: Sat Aug 26, 2006 2:52 pm
by Benjamin
Oren wrote:astions wrote:Umm, display errors shouldn't be turned on, on a production server anyway.
Not really. You got confused, I believe, with development server - there you should have error reporting set to all, and display errors turned on.
On a production server, turn display errors off

That's what I meant.
Posted: Sat Aug 26, 2006 2:57 pm
by RobertGonzalez
I would agree with that also. That is how I currently develop.
Posted: Sat Aug 26, 2006 3:01 pm
by Oren
astions wrote:Oren wrote:astions wrote:Umm, display errors shouldn't be turned on, on a production server anyway.
Not really. You got confused, I believe, with development server - there you should have error reporting set to all, and display errors turned on.
On a production server, turn display errors off

That's what I meant.
Oh, I'm sorry... I got it wrong, sorry dude
Edit: I read it too fast and I thought you said "should" instead of "shouldn't"

Posted: Sat Aug 26, 2006 4:12 pm
by bokehman
AKA Panama Jack wrote:I think the debate is still open on if error suppression slows down PHP. It may have on the early, very SLOW 3.xx versions of PHP but on the later PHP 4 and 5 it doesn't look like it. Removing the @ doesn't seem to increase the number of executions per second.
Just a bit of fun... I wrote this as a test:
Code: Select all
<?php
microtime(); // initialise
$start = microtime();
for($i = 0; $i < 1000000; $i++)
{
if(@$fake){}
}
$end = microtime();
$with_suppression = elapsed_time_in_milliseconds($start, $end);
$start = microtime();
for($i = 0; $i < 1000000; $i++)
{
if(isset($fake)){}
}
$end = microtime();
$without_suppression = elapsed_time_in_milliseconds($start, $end);
if($with_suppression > $without_suppression)
{
echo 'Without error suppression is '.round($with_suppression / $without_suppression, 1).' times faster than with error suppression';
}
else
{
echo 'With error suppression is '.round($without_suppression / $with_suppression, 1).' times faster than without error suppression';
}
function elapsed_time_in_milliseconds($start, $end){
$start = explode(' ', $start);
$start = $start[0] + $start[1];
$end = explode(' ', $end);
$end = $end[0] + $end[1];
return (round(($end - $start) * 1000));
}
?>
It prints:
Code: Select all
// Without error suppression is 11.4 times faster than with error suppression
Posted: Sat Aug 26, 2006 4:20 pm
by Ollie Saunders
Ahh bokehman does what he is best at.
Without error suppression is 11.4 times faster than with error suppression
Superb.