Up until this point, I have always hard-coded errors on my websites. The thinking being that they will load quicker and the chances that they wouldn’t load are minimal.
How risky would it be if I moved all of my customized error messages into MySQL?
My fear is that if MySQL or my SQL puked then the user wouldn’t get an error message, but instead an error message on the error message?!
My personal opinion a user should never get an error, the error should either be logged or sent to an administrator via an email.
So if they enter 1,000 instead of 1000 and don’t get an error then how are they to know that they need to remove the comma?
It all depends on the reason for the error. If the error is the user’s fault then they should get an error message. If it is a system fault then it should be logged. Either way storing them in the database should be fine - particularly since the info the user is entering needs to be processed against the database anyway so if the DB is down then their input will not work even if they don’t make an error.
Yes, there is a big difference between
“Sorry, system problems, please try again in a few minutes”
and
“Error in ‘/database/connect.php’ line 12, Unable to write to member_emails field in member_data table”
And I’m talking about the first and not the second.
If the database is puking, it should have an error reported in a log and usually the admin should get some sort of notification (an email as a minimum). The user should get a “Sorry, we are out of order.” page. Storing the text for any other error messages in the database or a central file or caching system is a normal practice, especially for scaling apps.
Scott
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.