在迭代器中的finally块中引用异常

Question

Is there any way to get a reference to an exception inside a finally block in an iterator function or property that allow try..finally but not try..catch ?

I'm not going to use it to change or mess with the control flow, but would like to be able to get a reference to the exception in the finally block anyway (if one was thrown), in order to read from it and possibly add stuff to the Data member .

I understand that due to nature of the compiler generated classes from iterators, it is probably not possible/allowed for the same reason why try..catch around a yield statement is not allowed in the first place. But I'm still hoping that there is maybe be some way (or even ugly trick) to get hold of the exception anyway.

Simplified example:

IEnumerable<SomeClass> Something
get
{
  try
  {
    throw new SomeException();
    yield return new SomeClass();
  }
  finally
  {
    Exception ex = ... // <= TODO - get hold of the exception here [if one was thrown]...
  }
}

Answer 1

This is a very interesting question.

Recall that in Linq, a lot of standard operators are provided that effectively chain together. There currently isn't one that lets you wrap custom exception handling around an inner sequence.

So my suggestion is to write a new one that allows you to specify an action that handles any exception that occurs during the execution of IEnumerator.MoveNext :

public static class EnumerableExceptions
{
    public static IEnumerable<TItem> Catch<TItem, TEx>(
        this IEnumerable<TItem> source, 
        Action<TEx> handler) where TEx : Exception
    {
        using (var enumerator = source.GetEnumerator())
        {
            for (; ; )
            {
                try
                {
                    if (!enumerator.MoveNext())
                        yield break;
                }
                catch (TEx x)
                {
                    handler(x);
                    yield break;
                }

                yield return enumerator.Current;
            }
        }
    }
}

So now supposing we had this:

public class NastyException : Exception { }

public static IEnumerable<String> StringYielder()
{
    yield return "apple";
    yield return "banana";

    throw new NastyException();

    yield return "oracle";
    yield return "grapefruit";
    yield return "microsoft";
}

We'd like to be able to wrap all the body in a try / catch , which is sadly illegal. But what we can do is wrap the generated sequence:

public static IEnumerable<String> LoggingStringYielder()
{
    return StringYielder().Catch(
        (NastyException ex) => 
            Console.WriteLine("Exception caught: " + ex.StackTrace));
}

That is, I get a sequence by calling the "raw" StringYielder method, and then I apply the new Catch operator to it, specifying what to do if a certain exception type occurs. Here I'm just going to print the stack trace.

So if I do this:

foreach (var str in LoggingStringYielder())
    Console.WriteLine(str);

The program completes without crashing, and the output is:

apple
banana
Exception caught:    at ConsoleApplication7.Program.<StringYielder>.. blah

So although you can't put a try catch around the code inside the original iterator method, you can now "wrap" it around the outside of that iterator method. It's like a non-intrusive way of injecting exception handling around the code between each yield return .

Bonus update!

To be really picky about the way I worded that last sentence:

• Firstly you can throw before the first yield return and it is treated the same way, as that code executes in the first call to MoveNext . So "... the code before each..." would have been more accurate than "... the code between each...".

• Secondly, a yield return may accept an expression that has to be evaluated, and which may throw during evaluation. That should be regarded as code that executes before the yield return occurs, even though syntactically it appears after it.

Answer 2

How about moving all the code which could generate an exception into a nested try/catch:

IEnumerable<int> GetFoo()
{
    for (int i = -10; i < 10; i++)
    {
        Exception ex = null;
        try
        {
            int result = 0;
            try
            {
                result = 10 / i;
            }
            catch (Exception e) // Don't normally do this!
            {
                ex = e;
                throw;
            }
            yield return result;
        }
        finally
        {
            if (ex != null)
            {
                // Use ex here
            }
        }
    }
}

With the above pattern, however, you may be able to do everything you need just within the catch block instead, which would be simpler - you may be able to get rid of the surrounding try/finally block.

Answer 3

Knowing what exception is pending, if any, during a finalizer is a nice ability. VB.net makes it possible, though awkward. C# does not. In vb.net the technique is:

Dim PendingException as Exception = Nothing
  Try
    .. Do Whatever
    PendingException = Nothing ' Important -- See text
  Catch Ex As Exception When CopyFirstArgumentToSecondAndReturnFalse(Ex, PendingException)
    Throw ' Should never happen if above function returns false like it should
  Finally
    ' PendingException will be Nothing if Try completed normally, or hold exception if not.
    Try
      .. Cleanup
    Catch Ex as Exception
      Throw New FailedCleanupException(Ex, PendingException)
    End Try
  End Try

Note that this can be a very useful technique if code which would be triggered by an exception is guaranteed to end up either rethrowing the exception or throwing a new aggregate exception. Among other things, if the exception is going to be ultimately unhandled, the "Unhandled exception" debugger trap will fire when the original exception occurs, rather than the last time it's rethrown. This can considerably ease debugging, since a lot of program state will be available to the debugger that would otherwise be trashed.

Note also that the PendingException is explicitly cleared at the end of the main Try block. It is possible for PendingException to have a value even if there is no pending exception. This could occur if something within a doubly-nested Try block throws an exception which won't be caught within our try block, but the inner Try block's Finally clause throws an exception which is caught within the singly-nested Try block. In that case, the original exception effectively disappears. It may be good to generate a special log entry if either the the "CopyFirstParameterToSecondAndReturnFalse" or "PendingException = Nothing" executes when PendingException is non-null, since that scenario would probably represent a bug that isn't apt to be logged anywhere else, but if there are multiple nested catch blocks they could generate redundant log entries.

Given that C# doesn't support the exception filtering necessary for this approach, it may be helpful to write a VB wrapper which can call C# delegates but provide the necessary exception-handling logic.

It's not possible to do a yield return within a try-catch block, but I wouldn't see that would cause a problem with something like:

{
  Exception ex = null;

  try
  {
    CaptureExceptionInfoButDontCatch(ex,{
       /* Stuff that might throw */
    });
    yield return whatever;
    CaptureExceptionInfoButDontCatch(ex,{
       /* More that might throw */
    });
  }
  finally
  {
    /* If ex is nothing, exception occurred */
  }
}

Answer 4

finally blocks are meant for always-executed clean-up and hence are not intended to manipulate with exceptions — there can easily be no pending exception at all.

Using the catch block with a rethrow should work for you:

try
{
    // .. something throws here ..
}
catch (Exception ex)
{
    // .. do whatever you need with ex here ..

    // and pass it on
    throw;
}