Why can't yield return appear inside a try block with a catch?

The following is okay:

try
{
    Console.WriteLine("Before");

    yield return 1;

    Console.WriteLine("After");
}
finally
{
    Console.WriteLine("Done");
}

The finally block runs when the whole thing has finished executing (IEnumerator<T> supports IDisposable to provide a way to ensure this even when the enumeration is abandoned before it finishes).

But this is not okay:

try
{
    Console.WriteLine("Before");

    yield return 1;  // error CS1626: Cannot yield a value in the body of a try block with a catch clause

    Console.WriteLine("After");
}
catch (Exception e)
{
    Console.WriteLine(e.Message);
}

Suppose (for the sake of argument) that an exception is thrown by one or other of the WriteLine calls inside the try block. What's the problem with continuing the execution in catch block?

Of course, the yield return part is (currently) unable to throw anything, but why should that stop us from having an enclosing try/catch to deal with exceptions thrown before or after a yield return?

Update: There's an interesting comment from Eric Lippert here - seems that they already have enough problems implementing the try/finally behaviour correctly!

EDIT: The MSDN page on this error is: http://msdn.microsoft.com/en-us/library/cs1x15az.aspx. It doesn't explain why, though.

I suspect this is a matter of practicality rather than feasibility. I suspect there are very, very few times where this restriction is actually an issue that can't be worked around - but the added complexity in the compiler would be very significant.

There are a few things like this that I've already encountered:

• Attributes not being able to be generic
• Inability for X to derive from X.Y (a nested class in X)
• Iterator blocks using public fields in the generated classes

In each of these cases it would be possible to gain a little bit more freedom, at the cost of extra complexity in the compiler. The team made the pragmatic choice, for which I applaud them - I'd rather have a slightly more restrictive language with a 99.9% accurate compiler (yes, there are bugs; I ran into one on SO just the other day) than a more flexible language which couldn't compile correctly.

EDIT: Here's a pseudo-proof of how it why it's feasible.

Consider that:

• You can make sure that the yield return part itself doesn't throw an exception (precalculate the value, and then you're just setting a field and returning "true")
• You're allowed try/catch which doesn't use yield return in an iterator block.
• All local variables in the iterator block are instance variables in the generated type, so you can freely move code to new methods

Now transform:

try
{
    Console.WriteLine("a");
    yield return 10;
    Console.WriteLine("b");
}
catch (Something e)
{
    Console.WriteLine("Catch block");
}
Console.WriteLine("Post");

into (sort of pseudo-code):

case just_before_try_state:
    try
    {
        Console.WriteLine("a");
    }
    catch (Something e)
    {
        CatchBlock();
        goto case post;
    }
    __current = 10;
    return true;

case just_after_yield_return:
    try
    {
        Console.WriteLine("b");
    }
    catch (Something e)
    {
        CatchBlock();
    }
    goto case post;

case post;
    Console.WriteLine("Post");


void CatchBlock()
{
    Console.WriteLine("Catch block");
}

The only duplication is in setting up try/catch blocks - but that's something the compiler can certainly do.

I may well have missed something here - if so, please let me know!

All the yield statements in an iterator definition are converted to a state in a state machine which effectively uses a switch statement to advance states. If it did generate code for yield statements in a try/catch it would have to duplicate everything in the try block for each yield statement while excluding every other yield statement for that block. This isn't always possible, particularly if one yield statement is dependant on an earlier one.

I've accepted THE INVINCIBLE SKEET's answer until someone from Microsoft comes along to pour cold water on the idea. But I don't agree with the matter-of-opinion part - of course a correct compiler is more important than a complete one, but the C# compiler is already very clever in sorting out this transformation for us as far as it does. A little more completeness in this case would make the language easier to use, teach, explain, with fewer edge cases or gotchas. So I think it would be worth the extra effort. A few guys in Redmond scratch their heads for a fortnight, and as a result millions of coders over the next decade can relax a little more.

(I also harbour a sordid desire for there to be a way to make yield return throw an exception that has been stuffed into the state machine "from the outside", by the code driving the iteration. But my reasons for wanting this are quite obscure.)

Actually one query I have about Jon's answer is to do with the yield return expression throwing.

Obviously yield return 10 isn't so bad. But this would be bad:

yield return File.ReadAllText("c:\\missing.txt").Length;

So wouldn't it make more sense to evaluate this inside the preceeding try/catch block:

case just_before_try_state:
    try
    {
        Console.WriteLine("a");
        __current = File.ReadAllText("c:\\missing.txt").Length;
    }
    catch (Something e)
    {
        CatchBlock();
        goto case post;
    }
    return true;

The next problem would be nested try/catch blocks and rethrown exceptions:

try
{
    Console.WriteLine("x");

    try
    {
        Console.WriteLine("a");
        yield return 10;
        Console.WriteLine("b");
    }
    catch (Something e)
    {
        Console.WriteLine("y");

        if ((DateTime.Now.Second % 2) == 0)
            throw;
    }
}
catch (Something e)
{
    Console.WriteLine("Catch block");
}
Console.WriteLine("Post");

But I'm sure it's possible...

I would speculate that because of the way the call stack gets wound/unwound when you yield return from an enumerator it becomes impossible for a try/catch block to actually "catch" the exception. (because the yield return block is not on the stack, even though he originated the iteration block)

To get an ideea of what I'm talking about setup an iterator block and a foreach using that iterator. Check what the Call Stack looks like inside the foreach block and then check it inside the iterator try/finally block.