GitHub error reporting Logging errors on automated systems

Introduction

I’m a developer. More than that; I’m a nerd who takes joy in what he does; developing software. In a professional scope it is indeed nice that there are people out there kind enough and generous enough to want to pay me money to do what I enjoy. However this does not diminish the fact that I develop things in my spare time just… just because I can.

Most recently there has been a project of mine to rebuild my site using Jekyll, and if you’ve read any of my previous articles you’ll understand that this has occupied a lot of my attention, to the point that I’ve been writing one or two posts a day about the process. Involved in this rebuild was writing an automated toolset that kept the site up to date with various events. The main one being that I wanted to keep a track of my Xbox Live Achievements on here.

This was a process purely for my own amusement, but I wanted to make sure it was reliable, and that if any errors occurred that I would be aware of them, and potentially fix them, before they became an issue and the data I was receiving was tainted (I have plans for this data, oh yes, I have plans…).

Basically, I wanted a way that would allow me to get visibility of the process and any errors that were happening without having email inbox being filled with emails in the event of an error. My solution was simple - any error is caught and it sets up an issue in GitHub on the repo for the code. Since I’m a mac user, and have Mountain Lion installed I have been using GitHub for Mac purely as a way of receiving notifications on repos. Granted this is mainly so I know what’s happening on the repositories that we use for work, but why not take advantage of it for myself.

Implementation

I’ve kinda talked my way through it already in the introduction, but I suppose I better go for specifics. The main thing I did was create an event handler for a global even in node.js to watch for uncaughtException like the following:

process.on('uncaughtException', function uncaughtException(err){
  if(!err.noCatch){
    error.handle(err)
  }
})

The key point here, is if my error handler throws an error we don’t want to end up in an infinite loop - so any errors generated by the error handler are assigned a flag of noCatch so that we don’t end up in that situation.

My error handler process is pretty simple, it does a few things:

1. Pull existing GitHub issues for the repo
2. Check if any existing issues match the exception message being handled
   • If they do - add a comment with the exception stack trace (no such thing as too much information for a bug
   • Reopen the issue if it has been closed * If they do not - create a new issue using the exception message as the title

Pretty straightforward, really. My error handler class and full usage example depend upon my githubber library and can be found below:

Conclusion

This works pretty well for me in my personal projects, but I can imagine that if one were to implement this on a larger project thing would quickly become unmanagable. Especially if you were using the GitHub Issues as your regular issue tracking system. So I’m definitely not saying this is for everyone - this is just intended as a nice way for me to keep track of my things erroring.