Record Exceptions

Programmers are usually optimistic about their code. Most of the code I have read over the past few years have a well thought of “if” condition. Very few look into making the “else” equally better.

I spent the last few weeks optimising Brightpod to work better when things did not work as expected. The “else” part of the code, which had “return false” mentioned almost every where. After all, everyone who had worked on the codebase(myself included) was optimistic about the code we had written. We had tested it well and we almost never reached the “else” condition.

Last month, I noticed that we received a few complaints about things not working well. As the number of user’s using the system increased things which worked well before now started to fail. Issues on the production server can be tough to debug.

Recording exceptions was always on my list. From all the things I had on my plate, recording exceptions was not quite high enough, until 2 weeks ago.

For all major features where things could go wrong i.e “else” conditions or the catch part, we now use getsentry to record exceptions. Recording meta information about each exception also helps us be proactive about getting in touch with the user and letting him / her know when the issue they last experienced got fixed.

No longer is a user bug complain a mystery as we get to trace the error which caused the issue. Having data about exceptions on the production server has been really helpful. I can’t recommend using a exception recording software enough.

Sunil Shenoy @sunil
Made with