try finally as costly as try catch ?

Here is the important part when it comes to performance when an exception is not thrown. Since the protected regions are stored in a table and are not in the bytecode, and because the CLR does not need to worry about the exception handlers unless an exception is thrown, then there is no runtime penalty for having a try...catch block. For finally handlers it is a little different, because we do need to run those even when we don't have exceptions. However, since we can compute what we will need to run when statically, the JIT compiler can still emit code that jumps to the finally handler at the appropriate time, making the execution overhead of one of those most likely just a jump and a return.

http://www.programmersheaven.com/user/pheaven/blog/175-Do-trycatch-blocks-hurt-runtime-performance/

I would not have imagined this :: try finally is always incursive of overhead, try catch mostly is not... hmm.

What about that stored table in the protected region?

-- I'd always been told that try/catch incurred enough overhead to only use them when necessary --

++ I'd never use them to control flow of execution in my source code, for pete's sake ++

Ok so I read this: "I put everything inside of a Try/Catch.  just company programming practices."

And this: "try/catch comes with a lot of overhead."

If there is indeed a lot of overhead, then company programming practices may be a bit egregious...

----------

EDIT: I'm going to assert that try incurs overhead, regardless of its delegation to catch or finally or both, and therefore should be used only when necessary (this will help to decrease the program's memory footprint). Runtime may not be affected negatively...

I will do that, thanks, o-mountain-of-molten-lava.

@ Dexter, yep, that's the take I carry...

That's what I wanted to hear, Andy, thanks.

try { to hang the system under a wait cursor }  finally { restore the cursor }