views:

2016

answers:

5

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.

+2  A: 

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.

Radu094
I'm familiar with stack unwinding in C++, where destructors are called on local objects that go out of scope. The corresponding thing in C# would be try/finally. But that unwinding does not occur when yield return happens. And for try/catch there is no need for it to interact with yield return.
Daniel Earwicker
Check what happens to the call stack when looping over an iterator and you'll understand what I mean
Radu094
@Radu094: No, I'm sure it would be possible. Don't forget that it already handles finally, which is at least somewhat similar.
Jon Skeet
+3  A: 

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.

Mark Cidade
I don't think I buy that. I reckon it would be entirely feasible - but very complicated.
Jon Skeet
Try/catch blocks in C# aren't meant to be re-entrant. If you split them up then it's possible to call MoveNext() after an exception and continue the try block with a possibly invalid state.
Mark Cidade
+7  A: 

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!

Jon Skeet
A good proof-of-concept, but this strategy gets painful (probably more for a C# programmer than for a C# compiler writer) once you you start creating scopes with things like `using` and `foreach`. For example: `try{foreach (string s in c){yield return s;}}catch(Exception){}`
Brian
A: 

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...

Daniel Earwicker
Yes, you'd put the evaluation into the try/catch. It doesn't really matter where you put the variable setting. The main point is that you can effectively break a single try/catch with a yield return in it into two try/catches with a yield return between them.
Jon Skeet
A: 

There’s a pretty good explanation of this C# design decision by Eric Lippert here:

http://blogs.msdn.com/ericlippert/archive/2009/07/23/iterator-blocks-part-five-push-vs-pull.aspx

Diego Rivero
And you can see my thoughts on that rationale in a comment to that post. Basically I don't think it's right: it's based on (what I think of as) a misunderstanding of the relationship between `catch` and `finally`. `finally` is not related only to exceptions, so it already runs in situations where `catch` does not - and quite properly so. Of the two possible behaviours they considered, the "exception wormhole" approach would be crazy. The version considered in this question would be simple to implement and would eliminate a very common inconvenience in writing iterator methods.
Daniel Earwicker