Written by Scott Johnson on Apr 04, 2011

This post is part of a series we authored on another site which has since gone offline; HopToad: Exceptions Happen was originally published on August 17th, 2009.

I've recently started using Hoptoad and hit my first (few) snags with it. As you'd expect, I began by signing up for Hoptoad. Then, as often happens for busy developers, I got slammed wiith some bugs and almost immediately had to put it aside. When I went back to it a few weeks later what I discovered was that their main web site was pretty much missing the directions for how to use it. They turned out to be located in the plugin readme. And, yes, I can understand that but a simple getting started or FAQ on their site would have saved me some digging. And I suspect digging on the part of someone else.

Suggestion 1: Put the Hoptoad docs on on the site not Just in the readme

Sidebar: Why didn't a simple grep or TextMate search through my Rails application tell me this? Well I spun up a new git branch to work on Hoptoad and when I was digging around trying to get back to Hoptoad, that branch wasn't active, so I didn't find anything. Once I got Hoptoad running, I found that my previous behavior patterns from using Exception Notifier actually got my into trouble. Now this might be a heretical statement here but when you run a production website, I don't find that I actually get all that upset by an exception or two. I know if I was a purist I might argue that an unhandled exception should never be thrown. But, the reality of websites in a heavily crawled environment is that exceptions happen. One example of this is Googlebot caching things that no longer exist on your site due to a code re-organization and an exception being thrown when it calls a controller that no longer exists.

The architecture of Hoptoad is that when an exception is thrown, a single email is generated back to you when an exception occurs. And the idea is that you don't get an email everytime for every single exception, only the first time. Instead you have a web based inbox for exceptions that you visit after the first time. Now given that the email is generated after the first time, you (or at least me) don't always go back regularly. If you used to use Exception Notifier, which I'd argue is Hoptoad's biggest competitor, you tend to rely on frequency of those emails to tell you "Oh Crap -- You need to pay attention HERE". So what got me into trouble was my deploying a less than perfect code fix and then getting only a single exception in my inbox while 70+ actually valid exceptions stacked up in my Hoptoad account.

Suggestion 2: Give users of Hoptoad a threshold where if enough exceptions are thrown, additional emails are generated.

Configuration Tip: Making Hoptoad Ignore Certain Errors

To address the problem above where I got exceptions triggered by crawlers, you can configure Hoptoad so that certain exceptions are actually ignored. Here's how to do this:

1. Open config/initializers/hoptoad.rb
2. In the HoptoadNotifier.configure block make it look like this:

HoptoadNotifier.configure do |config|
  config.api_key = 'your_api_key_here'
  config.ignore << SecurityTransgression  # custom exceptions written for our code
  config.ignore << CustomNotFoundError    # custom exceptions written for our code
  config.ignore << NoSuchUser             # custom exceptions written for our code
  config.ignore << ActionController::MethodNotAllowed
  config.ignore << Ultrasphinx::UsageError
end

Now those are the exceptions I've found that, for my application, I just don't care about. Your exceptions will vary (YEWV) but just drop the exceptions that you find aren't needed to watched here and then you can pay greater attention to the exceptions that vary.

Conclusion

Don't get me wrong here -- Hoptoad works great! The good folks over at ThoughtBot have done a superb job in building Hoptoad. My suggestions are merely an extra layer of icing on an already great cake. Thanks for building this wonderful product.