Should I track my handled exceptions?

Question

Various analytics tools will track the number of handled and unhandled exceptions (crashes) that happen in an app. This obviously helps us find problems we didn't know existed and will fix it.

Quite often, exceptions happen in try-catch blocks and are handled, but in many cases they still are situations that should not arise.

Should I keep tracking these exceptions in my analytics ?

On one side, I think yes, of course. The problem still persists, its handled (or sometimes even silenced...), but the reason its happening is still very much there and should be dealt with.

On the other side, I think no. We've already added the safety net we deemed sufficient and we know the client will never allow time to actually fix bugs. So this data is just cluttering our crash logs more than anything now.

My question is :

• Should someone track handled exceptions in analytics in general? Even if its handled, I can see reasons to track them and not track them. What is best practice? Or is there something else to do entirely?

Answer 1

On the other side, I think no. We've already added the safety net we deemed sufficient and we know the client will never allow time to actually fix bugs. So this data is just cluttering our crash logs more than anything now.

I agree with your explanation up until this point. The purpose of tracking/logging is not to provide a list of "things the customer wants to have fixed". You shouldn't omit it from the list just because you expect the customer to not want to fix the issue.

Very simply put, how are you going to remember that this is an issue, should the customer open up the budget for bugfixing in the future?

Or how are you going to deal with a second customer who buys this product, who does offer a budget to fix the issue?

The assertion that the log should only reflect things the customer might want to pay to have fixed is simply not correct. "Things that are going wrong" and "things the customer want fixed" are not different names for the same thing. They are two very separate things.

Should someone track handled exceptions in analytics in general?

What is the point of analytics if you're willfully going to hide things from it?

There's a difference between e.g. filtering certain "known and ignored" messages from your view (which is fair enough) and not putting them on the list to begin with (which leads to incomplete analytics).

Answer 2

Generally ALL your exceptions should be handled, even if just to return a friendly error message or to keep your application running.

Also, you should never expect an exception (it's one of their 3 weapons) in normal operation.

Therefore, yes you do want to log and track them, raise alerts etc.

Edit - to clarify not expecting exceptions.

Say you have an api call to a third party. You know that the third party is unreliable and will drop 10% of requests. The advice from them is "just resend!"

Your normal code might raise an exception on a failed request. Although you know the internet is not 100% reliable you don't expect requests to fail and want to be alerted if they do.

Your special code for this api has some built in retry logic, Rather than throwing on each failure and handling the exception with a retry, the first 2 failures don't raise an exception at all and the third failure does.

This allows finer control over the exact retry conditions, keeps exception catching out of your logic and allows a consistent "log all exceptions" exception handling logic.