Not raising StopAsyncIteration exception in debugger

[efasjdkfdalfgerio]

When "Raised Exceptions" is checked the exception StopAsyncIteration gets raised everytime when the async for loop ends.

This can be frustrating because an exception being raised at the end of for loop is not natural.

Code to trigger the exception:

import asyncio

async def gen():
    for i in range(10):
        yield i

async def run():
    async for p in gen():
        print(p)

if __name__ == "__main__":
    loop = asyncio.get_event_loop()
    loop.run_until_complete(run())

[int19h]

This is the unfortunate artifact of how async loops are implemented. But we should be able to special-case this exception type, like we already do for some others.

Although, what if you do want this exception to break, in some other circumstances? I'm not sure if we can determine whether it's raised from the loop, or for some other reason.

[efasjdkfdalfgerio]

Well @int19h, I think an ability to ignore this Exception would be a great thing.

1. But I'm in opposition of this because throwing an exception when a for-loop ends should be the implementation level detail and should not bubble up to the user.
2. This exception isn't really useful in the code to catch attention of the user.
3. Simplicity, I didn't know about this exception and thought my program is doing something wrong like throwing an exception in the async generator which is a waste of time.

[int19h]

It's not quite an implementation level detail, because it's spec'd as part of the language:

https://www.python.org/dev/peps/pep-0492/#asynchronous-iterators-and-async-for

Consequently, if you're implementing an async iterator manually, you'll need to raise that exception yourself. And when debugging such code, it can be useful to break on it. It's a relatively rare case compared to using async iterators, so I think there's a good argument for the default experience ignoring it. But we still need to accommodate the other case.

[fabioz]

We could have some more fine-grained support to allow users to define which exceptions should be accepted and which exceptions should be ignored.

Maybe we could have in the launch configuration something as:

{
    "exceptions": {
        "accept": ["BaseException"],
        "ignore": ["StopAsyncIteration", "GeneratorExit", "StopIteration"]
    }
}

Those would affect user unhandled and handled exceptions (but not unhandled exceptions (the default would be the configuration above).

As a note, we do actually already have hardcoded ignoring of GeneratorExit and StopIteration (so, simpler could be just adding StopAsyncIteration to that list and then if someone complains they expected it to stop there we could enhance the feature to support the configuration above -- although having a whitelist of exceptions to accept may be a nice to have too).

What do you think?

[madhur4127]

Instead of JSON settings I would intuitively expect a edit button in "raised exception" in vscode.

Other than this, I feel atm, it makes async code pretty undebugable because I've to "continue" everytime.

I like your idea @fabioz good one.