Eric Lippert explains this in great detail in his blog series about iterator blocks. Start at the bottom and work your way up, and don't skip anything until you've reached the right bit.
I'm not going to try to explain it beyond that - but I'll quote part of post 5, which is actually the one which talks about try
blocks which have catch
blocks (post 4 talks about catch
blocks themselves, but that's a different matter).
So what if the try block has a catch?
The original designers of C# 2.0 -- and remember, this is long before my time on the team -- had a huge debate over this. A debate which was repeated in miniature when I sent them all an email asking for the justification for this decision. There are three basic positions:
Do not allow yield returns in try blocks at all. (Or blocks that are sugars for try blocks, like using blocks.) Use some other mechanism other than "finally" to express the idea of "this is the code that you run when the caller shuts down the enumeration."
Allow yield returns in all try blocks.
Allow yield returns in try blocks that have finally blocks, but not if they have catch blocks.
[snip]
The down side of (3) is that the rule seems arbitrary and weird -- until you read five unnecessarily prolix blog entries that explain what on earth the design team was thinking.
Obviously, they picked (3), and now you know why.