Why you should avoid Try Catch blocks

A try catch block is the ultimate “rescue” for a novice programmer. Got a problem you can’t fix? No problem! You can just put a try catch around it! Unfortunately in my experience that mentality always ends up biting you in the ass, mainly because you cannot simply “suppress” errors in your code. Try Catch blocking is what I commonly call the “bandage” approach to programming. You know you have a problem and you don’t want to fix it, so you just Try Catch it and off you go!

As tempting as it is to use a try catch block on a lot of things, and trust me I have this temptation constantly, it should be avoided.

So what are try catch blocks for anyways?

Try catch blocks are present in almost every modern language (as far as I know). They are there, now be very particular about this phrase, as a way to handle “code exceptions”. This means that when your code comes across an issue it cannot resolve, say parsing a “A” to a number, it skips over the rest of the try block and asks you “I have a problem I cannot solve on my own, what do you want me to do?”. This means, I must very much stress, that it asks “What should I do?” and not “What should I do, can I ignore?”.

Empty Catch? Your doing it wrong!

I see this over and over again. For some reason a lot of people just don’t get it. If you have nothing in your catch statement, you’re doing it wrong! When your code crashes, you need to handle that problem, there is no way out of this. A try catch block might be a temporary fix for whatever your problem is, but down the line it will cause issues for code that depends on whatever you did in the try catch (and did not execute all the way through). If I was getting a name out of the database and that record doesn’t exist, my database might throw an error saying “oops, can’t get record!”. If I decide to try catch it and not handle that issue, the name of my user is now blank or null. As a result the rest of my code is now executing without knowing something went wrong. Even worse I did not try to fix it. I have come across code numerous times that have an empty catch statement and then do something like this:


try

{

//Calls the database to get user

}

catch (Exception e) {}

if (userName != "" || userName != null)

the author simply doesn’t understand the concept of such code simply does not understand the concept of try catch

So why should I avoid them?

Because they are simply lazy and not worth it unless you really need them. In a lot of languages, Try Catch statements are expensive performance wise. You should be able to check if the the user exists first. Letting your code crash is like saying

Lets fly my plane, if the rotor falls off, then lets just handle the issue then and there. No need to check if the rotor is ok before we take off

The most common cause of exceptions is when data is inconsistent with the required input. Something is missing or something has not been provided (initialized or passed in) a long the way. The library or framework throws an exception as a way to tell you “hey, something is inconsistent, go fix it!” or “what you gave me cannot be processed, please check for valid input first”.

So what do you do? You check if what your putting into the system is valid. Make sure that the user does not enter a letter instead of a number. Or make sure that whatever is causing the exception internally is fixed or corrected. If statements are your best friend here.

So when CAN I use them?

Sometimes there is no way around it. If you cannot check if something is of the correct input you have to handle the exception yourself. But you HAVE to handle it. For instance if a socket closes in the middle of a data read or a write, it will throw an exception in the middle of the operation. As a result, you either need to change client state to something like “stand by” or try to smoothly close the connection and dump the resources. But you have to make sure that you’re handling things. One common approach I see all the time is empty try catching for inconstant data coming through a socket. The server spits out something you don’t like so you ignore it. Bad idea! If this happens you are not using the server socket connection for what it was made for or the server is not working properly. In either case, you at least in the moment of error have to inform someone about it and possibly close out of the connection. For this you would use the catch block.

Leave a comment