Tracking clientside errors is always a pain. There are services you can use that aggregate data from naive constructors like binding window.onError and the like, but for a long time these have felt a little blunt.

So about a year ago I put together an Angular error shipper, it’s purpose was to provide an easy interface to shipping clientside errors and exceptions to an arbitrary number of serverside endpoints all from within Angular’s stack. SO as to take advantage of all it’s own error handling and reporting.

I’ve just finished putting this together into a bower and npm module that you can checkout out (github.com/Joe8bit/angular-error-shipper).

It deliberately only does two things:

  • provide a sensible set of defaults for shipping error messages to a backend system (like LogStash)
  • provide a mechanism for the user to implement an arbitrary number of shipper middlewares

I’ve used this at a 3/4 clients already and it’s always been very successfully utilised. However, it has to be said this module is only as useful as the method you use for surfacing this data. I’ve found that the LogStash/Kibana combo works very well.

There are a couple of things on the roadmap for this module:

  1. Add the optional ability to run all or an arbitrary number of the shipper middleware’s in a WebWorker so as not to tie up the rendering thread
  2. Add the ability to turn off this error shipping when running protractor e2e tests, as anecdotally I’ve seen some performance regressions for it when e2e testing bad paths in complex UIs.

If there’s something more you want from it please feel free to create and issue on Github or reach out on Twitter!