When to Use TRY / CATCH

UPDATE: Due to some confusion and helpful feedback, this article may be more appropriately titled “When NOT to use Try Catch”. Its a sink hole that I’ve seen far too often working with a wide range of talent levels in the fields between consultant workers and past generations reintroduced to the codebase.

Being fault tolerant and catching errors is often an after thought when it comes to coding standards in businesses simply because we tend to think about how our software works, not how it breaks. We’ve all come across the “What were they thinking” code now and then, and I’ve started to notice a trend regarding unnecessary or improper Try Catching, and that is they show up most often from newer programmers or those experienced but unfamiliar or uncomfortable to a particular part of the codebase. While these are clearly not the right reasons to use Try Catch, I can’t recall ever seeing an official “When/Why to” article.

We’ve all heard the saying to stay away from Try Catch unless you really need to, but lets take a second to qualify “need to”. Need to is when the program flow leaves your control. In other words, if you can predict, detect and react to an error case before it occurs, then you need to and not rely on a try catch to do your thinking. Don’t be lazy, do the analysis and testing and you code will be cleaner, safer and faster for it. Lets take a look at a couple examples to illustrate the point.

You’re taking in some user input from a text box and plugging it into an equation to perform some calculation with it. The user may have supplied some letters which obviously could not be directly interpreted as a number and would cause an application crash. Here you can take the user input, inspect it and make changes before running any code that could cause an error. You are in control, so a Try Catch is not called for.

You are calling to a part of the system that a coworker wrote. He/She sent you the signature for the call which you use because you haven’t used been in this logic before. The code belongs to your company but its totally Greek to you. Since your company owns this code you should not be using a Try Catch. Learn that code and/or at least make sure it is stable and fault tolerant itself. Write some unit tests to test the extremes and know the rules of valid inputs. Then, in your code make sure that your inputs fulfill these constraints. If they do not, handle the situation properly by elevating the error or correcting course and trying again.

You are calling into a third-party DLL for some processing. You’re pretty sure that you know what’s going on in their code and that you’re passing all the correct inputs. Control has left you and you need to be fault tolerant, Try Catch can be appropriate here. You may have made this third party call a thousand times without error, but you need to be safe. I’ve seen time and again updates to third party DLLs make unannounced API changes and/or introduce bugs of their own, even when the third party vendor claims no such change occurred. Aside from this, many businesses are moving towards app virtualization and Cytrix environments with mapped user profiles. An improper mapping in one of these scenarios can easily break the link to a third-party control causing havoc in your system as a result. The only way you can be sure these scenarios will not bring down your app is to write fault tolerant code and use Try Catch appropriately.

When you have deemed a scenario appropriate to Try Catch, do not just apply is as a blanket to cover a crash. Catch to an exception object and inspect it, log it and/or report it. You should make sure you handle the program flow appropriately, because you don’t know who else is going to come into the downstream code later and be completely thrown off because an exception occurred and you buried it. By logging and inspecting the error you may be able to resolve the problem and not put users, support and the other programmers through bug tracking hell. Of course proper logging and reporting of errors is a whole other topic, we’ll get to that later.

This is a topic I really wanted to put out there as it’s been showing its head again and again over time. Hopefully this can save you from a couple headaches.

I’m super excited to hear back from you. If you have questions or comments please do below(no signup necessary). I will reply! You can also hit me on twitter (@KeyboardG).


Leave a Reply