5 Ways to Handle HTTP Server 500 Errors

5 Ways to Handle HTTP Server 500 ErrorsHow are you handling exceptions in your web applications?  Does your team have a strategy or do you just deal with failures as they come up?  If you’re like most development teams, you just deal.  Whenever something breaks, it’s an emergency.  Customer runs into a problem, you get called in.  You dig through the logs to quickly find the culprit and you look like a hero.

That’s one scenario.  Another scenario is that you don’t find the problem so quickly.  You are, after all, sifting through hundreds or thousands of users, sessions, threads, files, and servers.  When you do manage to find what you’re looking for, you still need to reconstruct the events and application state that lead to the failure.  Unfortunately, with every hour that ticks by without a fix, your reputation loses a little bit of it’s shine.

This doesn’t have to happen.  By making a few changes to your app up front, you’ll save a lot of time and your reputation later.

1. Use a Custom Error Page

I’ll start with an obvious change: replace your server’s default error page with a custom one.  Make sure it uses the same branding and theme as your app.  Your error message can be as stoic or funny as the rest of your site, but it should convey that:

  1. The error is your fault, not your customer’s.
  2. You’re looking into the problem.
  3. It’s okay for your customer to try again right away.

Here’s an example of what I would use.
Custom Server 500 Page

One thing not to do on this page is to include an error code or incident number.  Don’t turn your customers into your monitoring system.  They shouldn’t have to call or email you with an error number.  It’s your site.  You know who they are, you know what they were doing, and you know they had a problem.

A custom error page won’t make your site any more robust or save you time debugging, but it will make you look professional.

2. Log the Web Request

The first big time saver is to log all request data with exceptions.  This means whatever you can get your hands on from the HttpServletRequest (URL, headers, etc.).  Stack traces are great at telling you where your code stopped working, but they suck at telling you why.  For that you need the surrounding context.

Once you start recording web requests with every exception, you’ll no longer need to ask your customers silly questions like:

“Were you logged in?”
“What browser are you using?”
“What page were you on?”
“What did you type in?”

You’ll have all of this info and more.

There are a few different ways to put the request and stack trace together, but I prefer to use a servlet filter.  In this example I’ve used printlns to record the data, but you can do better with your favourite log library.

3. Log the Application’s State

The next big saver is to add your application’s state into the mix.  For this I suggest binding a thread-local to each web request.  The advantage of using a thread-local is that you don’t need to pass it around to methods, its thread safe, and it can be managed by the servlet filter.

You can set the application values wherever makes sense in your app.  Since most of my apps don’t hold much state, I usually add these calls inside the interceptors for my web services, DAOs, and API calls.

 4. Notify Someone

Now that you’ve recorded all the info you’ll need to hunt down failures, it’s time to tell someone when there’s a problem.  Here again, you have several options.  You can use a log monitoring tool to scan for errors if you already have one.  These tools will usually take care of sending email alerts for you.

You can also fire off your own error emails from the servlet filter.  You just don’t want to do it for every exception or you could flood your inbox.  You also might not want to do it in the request thread.  Maybe queue it to a background task.

Either way, you should include all the things you’re logging — stack trace, web request, and app data.  Having all the data right in the email can save you a bunch of time, especially if you’re only using your phone.  You can also then just forward it if needed.

5. Save Errors in a Database

The final way to save your time and reputation is to log server errors to a database.  This will save you from having to scan files from multiple servers.  Servers you might not even have access to, in which case you’ll be waiting on someone else.

Using a database is just easier.  With one query you’ll be able to search across servers, files, users, sessions, threads, etc.  It’s even better if your database has full-text search built-in.  And if you put a web interface on it, then your testers and support people can use it too.


About Dele Taylor

Dele Taylor is the founder of StackHunter.com -- a tool to track Java exceptions. You can follow him on Twitter, G+, and LinkedIn.

No comments yet... Be the first to leave a reply!