Monday, September 16, 2013

Newbie series: Thinking about Exception Handling

You do your best to write good tests but sometimes things go awry with your Rails application. It could be a service you depend on went down or perhaps a bot starting hitting a URL that you didn't expect. In any case, stuff happens and you'd be smart to make a note of those errors so you can find and fix them. There are a number of ways to get this done. In development you've got the standard Rails stack trace and you may also use Better Errors. But what about staging or production? Let's take a look at some possibilities and see how they might fit in to your application.

1. Exception Notifier

One of the most basic forms of exception notification comes from adding a gem to your project. There are several gems out there but the basic idea is that any time there's an error, you'll get an email sent to you with the stack trace. Some will even store the exception in your database to review later. This is perfect for development or small projects where you are the sole developer. One advantage is that you get notified where it hurts the most: your email.

There are downsides though. For example, what if you aren't the only developer? Forwarding stack traces isn't really practical and may not necessarily convey a sense of urgency to the others on the team. Likewise, sending emails to everyone on your team makes it difficult to immediately understand who is responsible to handle the exception and what the process is to resolve it.

Lastly, the same exception being triggered multiple times (by a bot, perhaps?) can quickly fill up an inbox. Worse still, if your rails app depends on an external SMTP service like SendGrid, you might find yourself over their limit causing yet another problem for you to deal with.

Conclusion => Good, but best for individual developers

2. Party Foul
Understanding the limitations of the Exception Notifier gem approach, you might take a look at Party Foul. Unlike Exception Notifier which sends an email to one or more developers, Party Foul will open up an issue for you on Github for each notification.

Now the first thing you'll realize is that you need to have your code stored up on Github for this to make any sense for you. Assuming that's the case, what are some advantages of Party Foul?

  1. Github handles the email. That means if a team member isn't on the project or subscribed to notifications, they won't get bothered.
  2. Easy to assign an exception. Since Github already supports assigning issues, pointing this exception to a person is easy. Later, you can also point the fix to a specific git commit. Handy!
  3. Multiple exceptions of the same type are collapsed. You may still get multiple emails depending on your notification settings, but Party Foul is smart enough to know not to open up a new issue for the same exception. Score!
Conclusion => Better, but best for small teams

3. Roll your own
Chances are if you're an Enterprise you've been writing code long before Ruby on Rails came on the scene. In those cases, you've almost certainly got your own bug tracking system and don't want or need a gem to do anything special. If your BTS has an API, you might be able to customize the open source Exception Notification gems to send data in the appropriate format. Big companies are able to use big solutions. Lucky you!

If you need help understanding Rails Exceptions, we recommend checking out this useful presentation by Simon Maynard.

Conclusion => Enterprise problems call for Enterprise solutions.

4. Third party services
There are a number of third party services that can help you identify Exceptions within your application. We aren't in the business of endorsing any so we'll just give you a list and let you do the research to determine if any of them are good for your project:

No matter what - definitely be sure to track your exceptions and fix them! Also, we are looking for ONE senior Ruby developer in Washington, DC. Fantastic benefits - please see our listing on Stack Overflow.

No comments:

Post a Comment