Handling Errors: Beyond the 500 Internal Server Error
I just found out over the weekend that my snazzy new-customer-easy-signup process got broken a few weeks ago by a security update. Oops.
Normally, when something breaks, I get an E-Mail saying so, and the code presents the user with a mea culpa (just so that we’re clear that any programming glitch is my problem, not theirs).
That E-Mail is more or less my cue to drop everything and fix it, which is usually a matter of just a couple of minutes, if that. My codebase isn’t nearly complex enough that I subscribe to the “some bugs aren’t worth the cost of fixing them” philosophy, especially when it comes to your typical 404, 403, and 500 errors (file not found, forbidden, and internal server error, respectively).
The E-Mail also tells me who encountered the problem (if they’re logged in), so I can follow-up with them, apologize, and let them know that the problem is fixed. It’s not quite as good as not having problems in the first place, but it comes close.
In this case, though, the cause of the problem looked to the code like it was a trivial user error (user clicked “Send Letter” without attaching any files), so it presented a helpful error message (if that were actually the problem), and didn’t bother to let me know.
Unfortunately, that wasn’t actually the problem. The problem was that there was a rule that was redirecting insecure http:// requests to their secure https:// equivalents on-the-fly (geek speak: 302 redirect), but that rule was causing the files to get lost (geek speak: POST became GET).
As a result, the user would attach the files, upload the files, wait for the upload to finish, and then get an error message saying that they hadn’t attached any files, and to try again. It did have a link to the contact form as well, which is how I eventually found out about it, but that’s still not good.
So, the problem is now fixed, and I’ve contacted everyone who I think (based on the server logs) was affected by the problem, to apologize. In some cases, rather belatedly.
And I’ve learned another lesson about error messages and error reporting. It’s not good enough to just have the code E-Mail me when there’s a problem that it couldn’t handle. I need to have it E-Mail me when there’s a problem that the user wouldn’t expect, as well. That way, even if it is a trivial error, if it’s keeping the user from accomplishing their goal, I can follow-up and redesign the process.
That will be a good thing to remember as I go through the code over the next few weeks looking for ways to improve the user experience.
