Ah, the Internal Error. Mr HTTP 500. Something every developers hates to see in their inbox on a Saturday morning.
I’ve been noticing a problem with how internal errors are presented recently. I like to call it the “Doctor, I don’t feel good problem”.
Doctor, I don’t feel good problem
Patient: “Doctor, I don’t feel good”
Doctor: “What’s wrong?”
Patient: “I don’t know, you’re the doctor. Make me feel better”
Or as a developer:
Customer: “The website has an error”
Developer: “What’s wrong?”
Customer: “I don’t know, you’re the programmer. I don’t know anything about Ruby on Rails. Just fix it.”
Solving the Doctor Problem
This problem creeps up with both technical and non-technical users and is caused by poorly designed error pages. The default 500 error page for Rails looks like this:
Rails doesn’t say much here, just that something went wrong.
To fix this you want to design an error page that gives the user enough information to know if they should ignore the error or if they should report it.
I’ll repeat that because it’s important
An error page should give the user enough information to know if they should ignore the error or report it.
As long as the Rails environment is working you can still use Ruby and different exceptions to customize the error message. Try organizing your ApplicationController so it can rescue common exception and present different error pages based on the error. With Rails 2 you can use rescue_from or rescue_action_in_public (the former will bypass hoptoad and possibility other exception notifiers). With Rails 3 you can use config.exceptions_app which lets you route errors to another app or specific controller (see José Valim’s post for more details). For example, database errors might render the errors/database.erb.html page while code using a 3rd party API could render errors/twitter.erb.html.
On the other hand, if there is a framework or server error, such as boot errors, you’re going to have to use your web server to present a generic HTTP error (e.g. ErrorDocument configuration in Apache). This isn’t optimal but if Rails isn’t even able to run, you have a much larger problem on your hands.
The main thing you want to do is to help the user understand why there was an error and if they need to do anything about it. An error with their account is a different error from when a database can’t be reached.
[box type=”note” style=”rounded” border=”full”]How do you present your errors to users in your apps?[/box]
For the 500 error page, I simply add a line saying “the administrators have been notified of this error”, and make the backend send me an email with a detailed error log. I don’t remember the name of the gem that does this, but it’s very easy to configure.
It is useful to tell the user that an automated system has contacted the administrators but that alone isn’t enough.
The problem with a general message like that is that the user is left with no information about what to do. Should they retry what they just did? Should they come back later? Should they contact the administrators?
The exception notifier gem is probably what you’re thinking about.