Page 1 of 1

Handling database errors

Posted: Fri Mar 02, 2012 2:17 am
by social_experiment
I've created a database connection class that is extended by a search class. The database class throws an exception when any database connection and selection errors occur.

The working of the search class is dependant on the availability of the database so i thought about modifying the database connection class not to display an error message when it fails but to create an error array, containing any errors returned from database connection / select issues. Based on the presence of this array the search class will then display (or not display) the search from. Should the form be absent there will be an error message displayed to notify users that the search option is unavailable. To notify me about the error i have an error reporting option (via email) in place.

My thinking behind this is that i don't want visitors to know specifics (such as an unavailable database) about why the search option isn't working; they should only know that it isn't available. By not displaying the search form i am also limiting errors resulting from functions such as mysqli_real_escape_string() or mysqli_query(); I do use the error control operator but i would rather prevent the error from happening than letting it die quietly.

Is this approach valid or should i rethink it?

Re: Handling database errors

Posted: Fri Mar 02, 2012 3:28 pm
by Christopher
It sounds like a valid approach. We recently had a conversation about this for the Skeleton Framework and decided to use error numbers (while still providing access to error strings). The idea was to disconnect the errors that occurred from how you present the response to the user. Error numbers would also help with i18n.

Re: Handling database errors

Posted: Mon Mar 05, 2012 7:06 am
by Mordred
You should *never* display raw error messages as coming from the database, could be a security risk. There is a class of attacks that rely on reflected error messages to leech data after SQL injection. Also it is of zero usefulness to the end user. Your approach with hiding the form seems nice, although a bit "too much work" for my taste. If you can't connect to the database, probably a large portion of your site wouldn't work anyway. Better show an all-in-one error splash and email the admin.

Re: Handling database errors

Posted: Mon Mar 05, 2012 7:44 am
by social_experiment
Mordred wrote:You should *never* display raw error messages as coming from the database, could be a security risk.
My thoughts exactly;

Re: Handling database errors

Posted: Wed Mar 07, 2012 11:08 am
by kon
I use the same approach that Mordred suggested. If something has gone wrong with database connection a “friendly” error splash appears and a special log is written in server to let me know all about that exception (of course not in public_html). Recently I added a service sending me SMS in those kind of exceptions.

Re: Handling database errors

Posted: Thu Mar 15, 2012 9:41 am
by whiterainbow
Agreed, I'd always opt for a generic connectivity message that hides all connection information, and specific error messages within the application itself. Raw error messages are one of the worst things a developer can do to a user!