-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
with exceptiongroup.catch({Exception: async_fn}):
is a tempting and silent footgun
#66
Comments
We could use |
I think I think that reuse of the context manager is rare enough that we should actually prefer the smaller number of checks done when a handler is actually called, to checking every handler when setting up the context. The downside there is that maybe we could have detected it earlier or more reliably in cases where the buggy handler is only very rarely invoked, which could be sufficient to justify having both checks... |
Ok, so the consensus is to use |
Sounds good to me! |
It's surprisingly easy to write a handler which silently discards exceptions that you thought were handled:
and in a large program, all too easy to miss your only warning:
...the problem being that we expect sync handlers, and so we just call it - which if it's an async function won't actually run the body of the handler, and thus won't re-raise any exception, which is treated as success.
IMO this code is unrecoverably correct, and we should bail out with an error as soon as possible. Based on Trio's internal comments we should rely on checking the return value rather than inspecting the handler callable - I suspect doing an initial branch on
is not None
would keep things super-fast for the vast majority of happy cases. Thoughts?The text was updated successfully, but these errors were encountered: