Efficient try / catch block usage?

Question

Should catch blocks be used for writing logic i.e. handle flow control etc? Or just for throwing exceptions? Does it effect efficiency or maintainability of code?

What are the side effects (if there are any) of writing logic in catch block?

EDIT:

I have seen a Java SDK class in which they have written logic inside the catch block. For example (snippet taken from java.lang.Integer class):

        try {
            result = Integer.valueOf(nm.substring(index), radix);
            result = negative ? new Integer(-result.intValue()) : result;
        } catch (NumberFormatException e) {
            String constant = negative ? new String("-" + nm.substring(index))
                                       : nm.substring(index);
            result = Integer.valueOf(constant, radix);
        }

EDIT2:

I was going through a tutorial where they count it as an advantage of writing logic of exceptional cases inside the exceptions:

Exceptions enable you to write the main flow of your code and to deal with the exceptional cases elsewhere.

Any specific guidelines when to write logic in catch block and when not to?

Answer 1

The example you cite is due to poor API design (there is no clean way to check whether a String is a valid integer except trying to parse it and catching the exception).

At the technical level, throw and try/catch are control flow constructs that allow you to jump up the call stack, nothing more and nothing less. Jumping the up the call stack implicitly connects code that is not close together in the source, which is bad for maintainability. So it should only be used when you need to do that and the alternatives are even worse. The widely accepted case where the alternatives are worse is error handling (special return codes that need to be checked and passed up each level of the call stack manually).

If you have a case where the alternatives are worse (and you really have considered all of them carefully), then I'd say using throw and try/catch for control flow is fine. Dogma is not a good substitute for judgement.

Answer 2

This is something that tends to be dependent on language and paradigm.

Most of my work is done in Java (and sometimes C++). The tendency is to use exceptions for exceptional conditions only. There are some questions on Stack Overflow about the performance overhead of exceptions in Java, and as you can see, it's not exactly negligible. There are also other concerns, such as the readability and maintainability of the code. When used properly, exceptions can delegate error handling to the appropriate components.

However, in Python, the idea that it is easier to ask forgiveness than permission reigns. In the Python community, this is known as EAFP, which is contrasted with the "look before you leap" (LBYL) approach in C-style languages.

Answer 3

That is not the best way of thinking about try/catch blocks. The way to think about try/catch blocks is this: a failure has happened, where is the best place to deal with THIS specific failure. That may be the very next line of code, it may be twenty levels up the call chain. Wherever it is, that is where it should be.

What the catch block does depends upon the error and what you can do about it. Sometimes it can simply be ignored (failure to delete a scratch file with no imortant data in it), sometimes it will be used to set a functions return value to true or false (java's int parse method), sometimes you'll exit the program. All of that depends upon the error.

The important part to understand is: catch block == I know how to deal with this.

Answer 4

Catch blocks should only be used for handling exceptions, nothing else and never ever for control flow. In any situation where you want to use exceptions to manage flow you would be better off checking pre-conditions.

Handling flow with exceptions is slow and semantically incorrect.

Answer 5

Should catch blocks be used for writing logic i.e. handle flow control etc? Or just for throwing exceptions? Does it effect efficiency or maintainability of code?

First, forget the notion that "exceptions should be used for exceptional conditions". Also stop worrying about efficiency, until you have code that performs unacceptably and you have measured to know where the problem lies.

Code is easiest to understand when actions follow in a simple sequence, without conditionals. Exceptions improve maintainability by removing error checking from the normal flow. It doesn't matter if execution follows the normal flow 99.9% of the time or 50% of the time or 20% of the time.

Throw an exception when a function is unable to return a value, when a procedure is unable to complete the expected action, or when a constructor is unable to produce a usable object. This allows programmers to assume that a function always returns a usable result, a procedure always completes the requested action, a constructed object is always in a usable state.

The biggest problem I see with exception handling code is that programmers write try/catch blocks when they should not. For example, in most web applications, if a database request throws an exception, there is nothing that can be done in the controller. One generic catch clause at the highest level is enough. Then the controller code can blissfully ignore the possibility that the disk has crashed or the database is offline or whatever.

Answer 6

Catch blocks should not be used for writing code logic. They should be used only for handling errors. An example is (1) cleanup any allocated resources, (2) print a useful message, and (3) exit gracefully.

It's true that exceptions can be abused and cause undesired goto effects. But that doesn't make them useless. When properly used, they can improve many aspects of your code.