You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
import trio
async def produce(send_channel):
async with send_channel:
print("in async with send_channel")
raise RuntimeError("kaboom")
async def test():
send_channel, receive_channel = trio.open_memory_channel(0)
with trio.open_cancel_scope() as scope:
scope.cancel()
await produce(send_channel)
trio.run(test)
print("where's the kaboom?")
Prints:
in async with send_channel
where's the kaboom?
I'm guessing this is because channel.aclose() is a checkpoint? Seems like this exception-eating might be the same or an overlapping issue as #455, but it was especially surprising to me, and I think might create user confusion as people start using async with foo_channel: in more and more places.
The text was updated successfully, but these errors were encountered:
It is. There's not much that Trio can do internally to fix that IMHO, but what about a
def __aexit__(self, *tb): # and/or __exit__
with merge_exceptions(*tb):
foo()
context manager that packages the exception(s) raised by foo, and the traceback if one exists, into a MultiError (or whatever Python's stdlib ends up naming the thing)? At least then we'd have a standard idiom that we can use, and the one additional line of boilerplate won't hurt (too much) (and can be checked for by a linter).
I ran into this today:
Prints:
I'm guessing this is because
channel.aclose()
is a checkpoint? Seems like this exception-eating might be the same or an overlapping issue as #455, but it was especially surprising to me, and I think might create user confusion as people start usingasync with foo_channel:
in more and more places.The text was updated successfully, but these errors were encountered: