I'm developing a number of error views for an ASP.NET MVC application (a not-found, unknown and general error view) and I'm curious to know how others would answer these questions:
What kind of verbage do you include on these pages?
What kind of information do you display to the end user?
What information do you log?
I don't think this question is particular to any web application framework so everyone is invited to participate :)
To the user:
"Sorry, an error occured. It has been logged and will be looked at"
or something like that. Anything else is too much for end users and doesn't help but rather causes confusion and chaos. Optionally, if you submit the error into an error tracking system, you might also display a reference number / tracking number of sorts - but even that usually doesn't really help.
At most, you might want to single out the "you don't have permissions to view this page" error separately and give another message for those errors - but I wouldn't go too far with that.
What you could present is a textbox allowing the user to describe what he was doing leading up to the error, and submit that to you via e-mail. In our experience, less than 5% of users really make use of that feature, however.
Really, what you need to do is log the error and all its info (message, stack trace etc.) in the background into a database table or something for you to analyze.
What kind of verbage do you include on these pages?
Enough to ensure the user that the error occurred through no fault of theirs, the development team will be looking into the matter shortly, and if they are concerned in any way, here is how to get in contact with us.
What kind of information do you display to the end user?
Just the text above - some sites get cute with the error page (which is fine) but I never really find that to be necessary.
What information do you log?
As much as possible! Any system data like profile information (email, username, IP address, etc.), the error message that brought them to the error page, what page they were on when they experienced the error, what time and on which day did the error occur...
Some things which I would never, never show:
Hide the SQL statement
Hide the default SQL error message; Especially for cases when 'MySQL database goes away' because it would dump the password and userid used in the connection.
Useful information for the user when there is an error are the type of error, an error code, and if possible, why the error occur.
As for logging information, in PHP I would log any updates and any transactions which could be cancelled or modified later on. This is important for some software where the state of a transaction changes and could be modified by various other administrators.
Well, the guys answered most of the (sub)questions. Here's my contribution:
3. What information do you log?
@: Whatever that can help you find the cause of the errors so you can fix them or do something about them. Ideally also the context on how an error occurs so you can replicate it for testing/debugging.
I love firefox version of an errorPage when they give you the "Oops, something went wrong" and then spend 4 paragraphs on apologizing... At the end you can e-mail the error to them so they can do absolutely nothing about it.
Use friendly and conversational language to apologise and explain that something went wrong. It wasn't their fault (even if it was) - reassure them. Tell them that the site operator has been notified and will look into the problem, and will try to fix it as quickly as possible.
Offer them somewhere to go, for example if they've landed on a missing page then suggest some similar pages with relevant content, of just refer them back to the homepage - don't leave them standed.
You might also want to provide something like a Fault Id, so if they contact you about the error then you can reconcile it with your logs.