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_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
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]