>> //Untested code.
>> $connection = @mysql_connect('localhost', 'USERNAME', 'PASSWORD') or
>> trigger_error(@mysql_error() . " connecting to mysql", E_USER_ERROR);
> mysql_error() *never* returns warnings... so why are you prepending an @ ?
If $connection is an invalid link, it most certainly does print an error
message.
I apologize for leaving out the $connection argument, however.
The correct code is:
$connection = @mysql_connect('localhost', 'USERNAME', 'PASSWORD') or
trigger_error(@mysql_error($connection) . " connecting to mysql",
E_USER_ERROR);
It's Bad Programming to rely on the default argument. I spent a *WEEK*
tracking down a case where the "Programmer" was connection to a different
database (he thought) and closing it, only he was closing his main
connection. But only sometimes, because he only called the sub-routine
sometimes. Arrrrggh.
[NOTE]
In very old versions of PHP, mysql_error() would not have the error
message in the event of a failed connection -- You'd have to check PHP's
internal error message variables/functions if you run this on really old
PHP versions.
[/NOTE]
>> @mysql_select_db('DATABASENAME', $connection) or
>> trigger_error(@mysql_error($connection) . " selecting database",
>> E_USER_ERROR);
> neither does mysql_select_db()
Once again, if $connection is an invalid resource, it will.
So if you manage to get a good connection in the mysql_connect() line
above, and MySQL *dies* on your server before you get to this line of
code, then you have a potential error condition that will trigger this.
That may not happen very often -- In fact, odds are it will happen very
RARELY. But it *can* happen, and not coding for it is Bad Programming.
I can guarantee this can happen, because it *has* happened to me. Once.
>> $query = "select name, description from whatever order by name";
>> $people = @mysql_query($query, $connection) or
> nor does mysql_query()
Repeat comments from above.
>> trigger_error(@mysql_error($connection) . " $query", E_USER_ERROR);
>> while (list($name, $description) = @mysql_fetch_row($people)){
> nor does mysql_fetch_row, unless $people is not a mysql-resource, (thus
> being false,) which you already checked for.
I guess you've never had your database connection die on you in the middle
of processing, eh?
Well, it *does* happen, occasionally.
Program for it.
Also, I come from a PostgreSQL background, where PHP generates a message
on the attempt to read past the last row (which ends the loop) so I'm in
the habit of using @ there anyway.
[NOTE]
It may be that case that PostgreSQL/PHP only generates a NOTICE level
message which you only see if you have error_reporting() cranked up to
E_ALL level. If you don't see the notice message, don't tell me I'm
wrong. Re-set your http://php.net/error_reporting and test again.
[/NOTE]
Even if I were solely a MySQL user, the database *CAN* go down in mid-loop.
>> echo "<P>$name<BR>\n$description</P>\n";
>> }
>>
>
> Not to be rude, but adding so many @s is usually considered bad
> practice, and makes debugging scripts a hell of a lot harder.
Read more carefully :-)
See all the http://php.net/trigger_error calls?
I'm actually setting the Reader up to have *BETTER* error handling than
the ubiquitous (and horrible) "or die()" construct.
Using trigger_error consistently allows one to use:
http://php.net/set_error_handler
some day, and do something useful, maybe even intelligent, with the error
handling.
Meanwhile, the @ suppresses the default PHP error message, but
trigger_error spews out a more complete error message, resulting in about
the same quality of debugging as "or die()"
It just gives one flexibility for tomorrow to do something smart when one
realizes how bad "or die()" is. :-)
I don't know how many million scripters are using "or die()" because they
think it's the Right Thing because it's in every example in the on-line
manual, and every post, and every on-line tutorial, except for the
occasional good tutorial about error-handling itself.
It's no tougher to use trigger_error() without an error handler than
die(), and at least maybe someday they'll be able to convert their scripts
to use a real error-handler.
So, bottom line: If you want to write sloppy code and not check for
possible error conditions, go right ahead. :-)
But don't be chastising me for writing GOOD code! :-) :-) :-)
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
