status quo regarding errors

[harkly]

I have a site that is going to go public and I am wondering what is the status quo on handling possible errors?

 

I have them turned off so they won't show and they will be sent to an email but what about on the user end? What should I have happen so the user won't get confused???

 

This is probably a stupid question but is there a way to check the page for an over-all-error vs putting an error check in every Select & Update?

 

What I would like to do, if possilbe: page opens - there is an error - kicks user to a new page - emails error to me. I have it all working just wondering if I can do some generic check and then execute everything.

[Jessica]

It depends on the type of error, but you should be capturing and handling them all within your code.

[harkly]

So I should handle them in each and every Select, Update ...?

[Jessica]

If you're talking about MySQL errors, you should have discovered any syntax errors or other problems during development, and then prevent them from happening in the first place.

[harkly]

That's where I am getting a bit confused. All my code works and I am not getting any MySql errors and any fields that require user input are handled within that code.

 

I wasn't going to put any error handling other then not to show but everything I read tells me I need to

[KevinM1]

You should still attempt to handle errors because you're not guaranteed that your db will have 100% uptime or that things won't get snafu'ed somewhere else.

 

When/if you experience an error, the user should be brought to a generalized error screen informing them that there was a problem and that it's being looked into.  Do not post actual error information, as that can inform would-be attackers about your infrastructure (indeed, many attackers intentionally throw garbage in form fields and query strings to see if the developer was foolish enough to leave error reporting turned on).

 

Above all else, code defensively.  Things happen.  "Working 100%" today doesn't mean anything tomorrow.

[harkly]

Thanks! I will continue on

[Jessica]

You should still attempt to handle errors because you're not guaranteed that your db will have 100% uptime or that things won't get snafu'ed somewhere else.

Agreed, which is why I specified to capture and handle them.

 

 

The way the OP is doing it sounds right. And no, you can't check the entire script for errors.

[kicken]

What I would like to do, if possilbe: page opens - there is an error - kicks user to a new page - emails error to me. I have it all working just wondering if I can do some generic check and then execute everything.

If your site has a single entry point where all requests run though, then you can wrap your code in a try/catch block and use exceptions for your errors. For example

try {
ProcessRequest();
}
catch (Exception $e){
LogError($e);
ShowErrorPage();
}

 

ProcessRequest() would route the request to whatever page needs to handle it. If you have an error with the DB or something else then throw an exception.

$sql = 'SELECT blah FROM foo';
$stmt = $db->query($sql);
if (!$stmt){
throw new Exception('Failed to query database, '.$sql);
}

 

You can create your own exceptions by creating classes extending from the built in Exception class. Doing so will allow you to do more selective catch blocks as well as provide better error reporting.