Limiting try block scope. Does it matter?

Question

Is there any performance benefit (particularly in C++ or Java) in keeping the size of try block small [aside from it being more informative to the reader as to which statement can throw].

Given the following method where i do not want to throw out of the method.

void function() throws Exception
{
    statement1
    statement2
    statement3 // can throw
    statement4
    statement5
}

Is it better to do this:

Option 1

void function()
{
    try {
        statement1
        statement2
        statement3 // can throw
        statement4
        statement5
    }
    catch (...) {
    }
}

or

Option 2

void function()
{
    statement1
    statement2

    boolean success = false;
    try {
        statement3 // can throw
        success = true;
    }
    catch (...) {
    }

    if (success)
    {
        statement4
        statement5
    }
}

Answer 1

At least with the compilers and exception handling mechanisms I've seen, there should be no difference. The depth at which an exception throw is nested can make a difference, but only when the exception is thrown and the general agreement is that in this case performance is something you can generally ignore.

Answer 2

I'm not addressing the performance issue, I think readability is more important unless you know you have a bottle-neck. That being said:

It really depends on how related statement1-5 are. If it is one logical operation that is performed in 5 steps I prefer option 1.

Setting a success flag at the end of the try block in Option 2 is very ugly and error-prone, I would not recommend this in any case.

Answer 3

option 1 is fine. THe fact that some of the lines don't throw is not relevant. For a start just look at the code, it looks crisper. There is no perf hit

you will however get lectures about indiscriminately eating all exceptions and ignoring them

This is the type of mismatch thing you get when transitioning from a layer of code that uses exceptions (or even embraces them) and a layer that does not. It seems that the layer above you doesnt like exceptions, and that the layer below does. Is there a reason that the layer above you doesn't like exceptions. What would happen if you needed to explain to the layer above why statement3 failed. THen you have to write horrible exception to return code conversion functions.

Answer 4

As others have said, there should be only minimal difference in the generated code between these cases. The "cost" of exception handling relates to how many temporary objects must be destroyed when the stack is unwound (and to a lesser degree, the number of places the code has to jump to do it). This scales with the depth of the stack -- how many function calls between where the exception is thrown and where it is caught -- not with the number of instructions executed between the beginning of the try block and the throw.