Will I See the MySQL Error or the PHP Error?

[Fluoresce]

if(mysql_num_rows($results)) {
     $sql = "UPDATE `table` SET `column` = '123' WHERE `id` = 1 LIMIT 1";
     $update = mysql_query($sql, $conn) or die(mysql_error());
     if($update) {
          echo "<p>The table has been updated successfully.</p>";
     }
     else {
          echo "<p>Sorry, an error occurred. Please try again.</p>";
     }
}

I wrote the bit of code above.  It works, but there's something about it that I don't understand.

 

If the update were to encounter an error, will I see the MySQL error message or the else statement error message?

 

How would you have written this code?

 

How could I have deliberately caused an error to see what happens?

 

I appreciate the help that I get on this site very much. Learning loads!

Edited October 13, 2013 by Fluoresce

[requinix]

You will see the MySQL error message (because that's what you do with the or die()). The same thing that would have triggered the else block (mysql_query() returning false) will also trigger the "or die".

 

Using that "or die" is bad. It's okay if you have it while testing your code, but when you're done and your queries work then it should not be there. For one, the error message will reveal information to the user that you really don't want them to know. For two, it completely halts your script preventing you from taking any action such as notifying you of an error or undoing previous actions. For three, die()ing means the user gets, essentially, a big white page of nothing but the error message and that is very user unfriendly.

 

Drop the "or die" entirely. You already have something that deals with the error so there's absolutely no need for it to be there.

[Barand]

 

 

How could I have deliberately caused an error to see what happens?

 

Easy ways are mis-spell a column/table name or add an extra comma somewhere so the query fails.

[Fluoresce]

Drop the "or die" entirely. You already have something that deals with the error so there's absolutely no need for it to be there.

 

Thanks for the help!

 

I use die() at the end of every mysql_connect() and mysql_query(), thus:

$con = mysql_connect("localhost", "", "") or die(mysql_error());

$result = mysql_query($sql, $con) or die(mysql_error());

Are you saying that, once I get the code working, I should remove die()? Is there no chance that mysql_connect() or mysql_query() will fail in the future?

 

I understand that I should remove it if I already have something more user-friendly dealing with the error, but what if I don't have such a thing in place?

[Fluoresce]

Easy ways are mis-spell a column/table name or add an extra comma somewhere so the query fails.

 

Sorry, silly question!

 

I actually tried selecting a row that doesn't exist before asking that question. There was no error, which is why I asked it.

[jazzman1]

 

Are you saying that, once I get the code working, I should remove die()? Is there no chance that mysql_connect() or mysql_query() will fail in the future?

No, I don't recommend you omitting die(), exit functions from the script. Just don't provide information about mysql error when the code on production mode is.

Some databases do not return back any errors when we're dealing with it.

[requinix]

Are you saying that, once I get the code working, I should remove die()?

I say yes. Using that mechanism is a bad user experience. If you don't care about your users seeing half of a page then go right ahead, but the best way to deal with it is to use some error handling code that will abort the script (if necessary) and output a complete page for the user to look at. Giving short messages like "failed to query database" is bad enough without screwing up your page at the same time.

[jazzman1]

I say yes. Using that mechanism is a bad user experience. If you don't care about your users seeing half of a page then go right ahead, but the best way to deal with it is to use some error handling code that will abort the script (if necessary) and output a complete page for the user to look at. Giving short messages like "failed to query database" is bad enough without screwing up your page at the same time.

 

Yes, agreed!

 

I just wanted to say him that the warnings coming from this database library don't stop the script from the flow of execution without die() or some other exit methods.

[Fluoresce]

I say yes. Using that mechanism is a bad user experience. If you don't care about your users seeing half of a page then go right ahead, but the best way to deal with it is to use some error handling code that will abort the script (if necessary) and output a complete page for the user to look at. Giving short messages like "failed to query database" is bad enough without screwing up your page at the same time.

 

I see.

 

Okay, so should I have something like this:

$con = mysql_connect("localhost", "", "");
if(!$con) {
     echo "<p>Error!  Could not connect to the database.  Reason: " . mysql_error() . "</p>";
}
else {
     // Rest of code
}

Or, since the connection works during testing, should I just have this:

$con = mysql_connect("localhost", "", "");
// Rest of code

Edited October 13, 2013 by Fluoresce

[Fluoresce]

And if I should have

if(!$con) {
     echo "<p>Error!  Could not connect to the database.  Reason: " . mysql_error() . "</p>";
}
else {
     // Rest of code
}

after every mysql_connect(), shouldn't I also have it after every mysql_select_db() and mysql_query()?

Edited October 13, 2013 by Fluoresce

[jcbones]

I would say "DON"T REMOVE THE die()", but change it to trigger_error().  This is so that when you site goes live, it will process it as an error, and store it in the log file with the rest of them. 

[mac_gyver]

there are conditions outside your control that can cause something to fail. for things like a database connection, even if you have successfully created a connection at one point in your code, that connection can break before or while you are trying to access the data. by having error checking conditional logic (or a try/catch exception block) around any statement(s) that can fail, your code will take an expected execution path and can deal with an error in a defined way.

 

when a step fails, you need to insure that the code takes an execution path that makes sense (so that you don't produce errors in the following code that is trying to use the result from that step) and displays/logs useful information. you would want to display a 'user message' to let the visitor know the page isn't going to do anything and what he might, if anything, do about it, and display (during development) or log (when live) system level information about the problem.

 

jcbones's suggestion above to use trigger_error() is the best way of controlling the display/logging of the system level error information. however, i disagree about using or trigger_error() on the end of a statement as that doesn't address the execution path the code takes when there is an error, unless you use E_USER_ERROR, in which case you might as well use a die() statement.

[Fluoresce]

I'm confused. There's lots of conflicting advice here.

 

I don't know anything about logs or errors. This is interesting!

 

Questions

 

1. I have raw access logs in cPanel. Are these the logs that you guys are talking about, or are there other, PHP-related logs?

 

2. If I use trigger_error(), will the error show up in the raw access logs?

 

3. Some of you have said to keep die(). Wouldn't this terminate the script and present only half the page to the user?

 

4. How exactly do I make sure that the error is logged and the user is presented with a clear message on a complete page?

[mac_gyver]

1. the web server's error log is where php will be logging errors and it is different from the web server's access log.

 

2. only if the php settings are set to log errors. the point about trigger_error() is it makes use of php's error_reporting/display_errors/log_errors settings. you can configure where it will send the output just by changing the php settings, one set for development to immediately display the system level information, a different set for a live server to log the system level information.

 

all of this is covered in the documentation. the trigger_error() link above doesn't directly go to the manual's page, try this one - http://us1.php.net/trigger_error

 

 

3. using die() will stop script execution. if your intent is to allow your script to continue running, don't use die/exit. the choice is up to the programmer and how he wants to handle a condition in his code.

 

 

4.  as to code that demonstrates this, here's an example -

// some statement or block of code that you want to detect and handle any errors for...
if( ! statement_that_can_fail() ){ // note: the ! (not) before the statement
    // something failed, handle that here...

    $user_message = "Sorry, whatever it was that you tried didn't work, try at a later time.";
    $system_message = "things you know about the error, such as the error message the database returned";
    
    echo $user_message; // display inline here or the code later on the page could display this where appropriate.
    trigger_error($system_message); // display or log this based on php's settings.
    
} else {
    // something worked, use the result from that something here...

}

// continue with the remainder of the code on the page here...