Exception Logging is always an interesting problem to solve. Depending on your needs you may have a simple log statement which writes to a text file, or you may need to have a full-fledged exception management module whichlogs exceptions to the database, categorized them, and generates notifications. There is no single solution for how to log and manage your exceptions. It helps then to be aware of as many techniques and options as you can; since you never know which will come in handy in a situation.

One method to log exceptions is to log them in the cloud. And there exists a useful service which makes your job easier.

A service in the cloud represents a service that is hosted on the Internet, available to you through an API, so that you have no idea how it is physically implemented. This makes things simple for you since you don’t have to worry about writing implementation code for the exception logging and reporting framework. You only need to call it.

The service that I am discussing is called HopToad. The service offers a simple to use API which allow you to log exceptions from your application. The exceptions are stored in the cloud and are available to you from a central web-based console. All the logged exceptions are presented in easy to understand and navigable way. For example, you can see which errors are occurring most often, or which one is the latest error that came up and from where. You can look at error details and stack traces.

The service developed to be used from within RubyOnRails applications. However, they have an open API, and can be accessed through any technology stack. K. Robertson has made a .Net wrapper available for logging to HopToad. It’s called HopSharp. It is fairly straight forward to use (just drop the DLL in your application and you are good to go). I can imagine that it would be straight forward to write a Log4Net extension for this service as well.

When to use this?

So, when would you use something like this. While the final decision to use this would vary from project to project and client to client, I can think of the following scenarios:

  • The application is a work in progress and you are expected to release a number of updates. Typically, in such scenarios, a lot of testing happens while the application is in deployed state. A logging framework such as this will allow you to monitor the application as it is being used, and priorities on bugs can be assigned based on frequency and severity.
  • You have an application deployed at multiple locations and you would like to see a consolidated view of the exceptions being reported.
  • As a way to save time and effort. This is a ready made framework where you don’t need to impart any effort for implementing an exception logging and notification system.

I am pretty sure that there are other such services out there.

Share and Enjoy

  • Facebook
  • Google Plus
  • Twitter
  • LinkedIn
  • RSS
 

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>