My use case:
I have a background task, say called "coordination". In that task, I want to catch any errors and push those to the user waiting in the main task and only continue running the background coroutine after the user manually resolves the exception. 

Issue:
When testing the behaviour with ``unittest.Case`` and using ``assertRaises`` to catch the exception, the background coroutine manages to just freeze. I have narrowed it down to ``traceback.clear_frames`` in ``assertRaises`` that causes a GeneratorExit in the background coroutine.

I believe this issue is a duplicate to https://bugs.python.org/issue29211, but wanted to provide another actual use case where it can pop up. Also even if the generator raises a GeneratorExit, why did the background thread freeze is still a mystery to me.

Script to reproduce in my case is attached.

So yes, the `clear_frames` function will force a running generator to close. See https://github.com/python/cpython/blob/3.7/Objects/frameobject.c#L566, it explicitly does a Finalize. Would that be the desired behaviour for assertRaises is not clear. I find it strange that catching an exception is closing my running coroutine.

The reproduce example can be lowered to something like::

    import asyncio


    async def background(error_future):
        try:
            raise ValueError
        except Exception as exc:
            error_future.set_exception(exc)

        await asyncio.sleep(1)


    async def main():
        loop = asyncio.get_event_loop()
        error_future = loop.create_future()
        task = asyncio.create_task(background(error_future))

        await asyncio.wait([error_future])
        exc = error_future.exception()
        import traceback
        traceback.clear_frames(exc.__traceback__)

        # Will block forever, as task will never be waken up
        await task


    if __name__ == "__main__":
        asyncio.run(main())

Very interesting. Thanks for reporting this issue. I'll definitely take a look at this before 3.8 is released.  For 3.7 you'll likely have to find a workaround.

For now, it seems like ``copy.copy(exception)`` before raising seems to prevent this behaviour. So for all exceptions originating from background tasks I raise a copy to the user, rather than the original exception. It prints correct stack, so no real impact on the library.