Are you asking if that's a good design?  (It can be very good and
useful, and it makes it very clear to a maintainer that there are two r
more levels of error handling.)

But the way it works, is that an exception thrown in the inner block may
be caught by the inner catch, if the type matches.  That inner catch can
re-throw the exception or not.  In either case, the inner block is gone
out of scope completely,  and control transfers to the outer block.  If
the inner exception is not caught by the inner block, the inner block's
finally still runs but the exception is still going to interrupt the
outer block in that case.

I'm doing a poor job of explaining.

Think of what happens when one method calls another and each method has
try-catch-throw-finally blocks.  The nested behavior is really a lot
like anonymous methods.

graniteraju@gmail.com said:

I think the above sentence is where your thinking goes muddy.
A try-catch structure is not loop. You'll never go "backwards" with
try-catch [-finally].

No; when an exception is thrown within a "try" block, the control will
be passed to the corresponding "catch" block. If the type of exception
thrown matches the type of exception for the "catch", then the catch
block will be executed. Otherwise, the exception will be passed to the
"catch" block corresponding to the enclosing "try" block, and handled
in a similar fashion.

After the exception has been handled in some "catch" block, the execution
will continue from the end of that "catch" block. If there was no matching
"catch" block, the thread will terminate.

"finally" blocks will be executed whenever execution exists a "try" block.
If there was a "catch" block matching the exception, the "finally" block
will be executed after the "catch" block.

But as said, your main issue seems to be to consider try-catch a form of
loop, which it is not. Drop that, and you'll see that the execution flow
is natural.