Is a try-catch-finally clause appropriate for production code?

Question

While browsing around on SO, I came across an answer that suggested using a try-catch-finally clause to fix the problem he was having. (A rare bug that sometimes happened to his users). Someone commented that it was a valid solution, but he said it was not recommended for production code.

Is this true? Why is it not recommended for production code?

It seems perfectly valid to me if it is used for catching exceptions. In this context it was for an app and users are very discouraged from continuing if the app just crashes seemingly randomly.

He also mentioned that it could fail at anytime.

Is this true as well?

Answer 1

In the linked-to question/answer, the correct solution is to fix the fact that the unsubscribe code is called more than the subscribe code. If there is not time to fix it, then ignoring that specific exception may be a usable short-term workaround. But we all know what that means in production code.

In the general case, there is no clear "one size fits all" answer. There are valid arguments for and against exceptions in general, but the truth is that certain languages and libraries use them so you may as well get used to dealing with them effectively.

Sometimes an exception is relatively harmless and should trigger other behavior than a rethrow. For example, if input is not a valid number (e.g. java.lang.NumberFormatException) and cannot be stored in a numeric field. Maybe there is a way to indicate this on the UI and retry the input operation.

Sometimes an exception is much more serious (e.g. std::bad_alloc) and your program might want to catch it, perform some minimal cleanup, and rethrow to kill itself. In the case of a std::bad_alloc it would, of course, be a bad idea to allocate more memory during cleanup.

What this means is you really need to evaluate every situation. Think "what caused this exception to be thrown?" and "what is the realistic outcome during this exception handler?" It could mean anything from input validation catching something wrong, to something so severe there is no way to recover other than to write a stack trace or line number to the log and quit.

Answer 2

Notice how the Try-Catch block in your linked answer doesn't actually do anything. He's not doing anything to mitigate the error, not even so much as reporting it.

This is why it might fail at any time. If whatever is causing that error happens again, and you try and use the object inside of the try block, he could cause an error later in the code, at seemingly random spots.

Try-Catch-Finally blocks are perfectly acceptable (and really almost mandatory) in production code, as they offer a means of falling back in exception enabled languages. You'd be hard pressed to find a piece of production java code that doesn't have any try-catch blocks of some sort.

To get into a little more detail, Exceptions are basically a way of telling the calling function that something went wrong. You could do this by returning a null, but then you have to go through all the remaining steps in that method. If you're in a 150 line method that's very resource heavy (querying a database, making calls to an external API) and you know right off the bat something is wrong (you didn't provide a username, you forgot to set a mandatory field) you can bypass all those extra steps and just raise an exception, exiting the function immediately. It also allows for you to bypass intermediary functions. If you're utilizing a lower class that throws an exception and you don't know what to do with it, you just pass it up to the higher class, where that exception might make more sense.