You might have been taught that when exception handling occurs, every method is considered separately. That is, since your inner method has a try...finally, any exception will first trigger the finally, and then it will “look” for a try higher up. This isn’t true.
From the ECMA specification of CLR (ECMA-335, I.12.4.2.5 Overview of exception handling):
When an exception occurs, the CLI searches the array for the first protected block that
- Protects a region including the current instruction pointer and
- Is a catch handler block and
- Whose filter wishes to handle the exception
If a match is not found in the current method, the calling method is searched, and so on. If no match is found the CLI will dump a stack trace and abort the program.
If a match is found, the CLI walks the stack back to the point just located, but this time calling the finally and fault handlers. It then starts the corresponding exception handler.
As you can see, the behaviour is 100% compliant with the specification.
- Look for a protected block –
tryinSomeOperation - Does it have a catch handler block? No.
- Look for a protected block in the calling method –
tryinMain - Does it have a catch handler block? Yes!
- Does the filter wish to handle the exception? The filter is evaluated (disclaimer: this doesn’t mean that all filters in the protected block will always be evaluated – no problem if the filter has no side-effects, which it really shouldn’t, of course), and the result is yes.
- Walk the stack back and execute all finally and fault handlers
finallyinSomeOperation
The finally in Main isn’t part of this, of course – it will execute when execution leaves the protected block, regardless of the exception.
EDIT:
Just for completeness – this has always been this way. The only thing that changed is that C# now supports exception filters, which allows you to observe the order of execution. VB.NET supported exception filters from version 1.