I'm want to get an idea how I should handle end-user visible error messages in my web application.
How much information do you give in error messages?
Do you redirect all errors, regardless of type, to a common error page, or do you have a small set of pages (404, 403, all others)?
Do you give error codes that the user could reference/give to you that only you understand?
Do you give any technical details?
As I stated, my users are non-technical regular Joe folks.
Display a nice error to the user, Log a detailed error for yourself.
I try to do the following:
In general I try to give users as much information needed to help them solve their problems themselves. For example, in the case of a 404, you might want to let them know to double check that the URL they are looking for is correct.
They obviously wont need stack traces, and the like, but it will make sense for you to log that level of detail somewhere for diagnostics and debugging.
for fatal errors, keep them short, so they can repeat them over the phone or e-mail: can't connect to database, etc.
for non-fatal errors, describe the condition fully: Error, can not save the invoice without an invoice date.
I also always log everything, the parameters to the function and any internal values that may be of use.
I try to show users enough information that they know it's an issue they need to tell someone about, but try to avoid showing them so much it scares them!
If possible the error message should tell them what just failed e.g did their save just fail, or has it saved fine, but the refresh of the screen afterwards had an issue. Extra error information (e.g. stack traces) should be logged somewhere where you can get at it without the user having to send it to you.
When it comes to displaying errors for the end user, I find it a good practise to display a errorcode (so me and administrators know what error it is) and a typical "ops something went wrong, please contact an administrator"
It can be good to give a bit more information for common errors that could be the cause of the users actions. But usually too much information can scare or confuse the user.
Your web application's error messages should always (at least) be the answers these 3 questions (in that order):
What happened?
Why did it happen?
What can be done about it?
I have used it for many years, originally from Apple's "Human Interface Guidelines: The Apple Desktop Interface". Newer version. Microsoft has similar guidelines.
This also makes it easy to write them - this structured approach makes it faster to write them as one can just answer the questions.
The error messages should also be specific. Any information that the web application know about and that the user may need to resolve the problem should be in the error message. The (infamous) error message "An error happend." is simply not acceptable.
Optional: more technical information that the user may not understand can be placed at the end. But it should be marked as such.
None, just show give a reference number so user can give it to you, and you can check the details from the application logs (obviously you need to keep a copy of error logs).