-
-
Notifications
You must be signed in to change notification settings - Fork 330
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
Ensure that our docs present strict_exception_groups=True
as the natural default
#2929
Comments
Relatedly, we should document any design patterns we like or dislike for interfaces with an "inner nursery", c.f. python-trio/trio-websocket#132 The basic problems are that (1) forcing users to handle errors which may or may not be an Unfortunately, this also means that using a nursery internally means that error handling doesn't quite follow the black box rule - you can still catch an ungrouped exception with Example patterns:
...and that's probably a decent outline for the section, I suppose. |
It's scary that these approaches to the nursery-as-implementation-detail problem haven't been fleshed out before committing to strict exception groups. I think the best practice for avoiding concurrent error headaches is to minimize their scope, converging on a winning exception in a local context wherever reasonable. Up until now, I've only had to deal with that in a few places in our app or libraries where a concurrent error might leak. Now every single use of a nursery (including as implementation detail by 3rd party libraries) needs to be bandaged over. It's a large blow to trio ergonomics. (6) sounds interesting, but I'm not sure if the body/background distinction is sufficient. I'd have to see it and try to apply it. The careful wrapping of API's alluded to in (7) has been the approach in my application all along, and has worked fine. For example, see |
I think it's related to the patterns discussion, so I'll share thoughts on how I might migrate trio-websocket to trio's new regime. This library seems like it would be a simple enough case-- no async package dependencies, doesn't expose concurrent errors in its API-- yet how to reach the goal isn't obvious. The points to watch for:
Between these, the latter has me more concerned. At least with the former, the code to review is clearly marked with So, along the lines of pattern (2), I might make a context manager that translates ExceptionGroup into an internal error, unless the group consists entirely of Regarding pattern (2):
No one should be explicity catching an internal error of an API (a general catch is fine). I guess here I'm equating "internal error" with "error that the API does not expect to raise", so it's a bug to be fixed. It's important to use a dedicated error and make it clear that a bug should be reported. |
I'm not delighted about this gap either, but #2785 (comment) explains why I think we had to do it: strict is the standard semantics across I think I'm less bothered by the worse ergonomics because those bugs have repeatedly bitten me, in both our own and upstream code, and I'm working in a large enough codebase that buying reliably-correct-ness for some convenience is net-positive tradeoff. In cases where you know that only one error can every happen at a time (although how sure should we be that we'd notice if that changed?), it's not too hard to flatten the group - although it'd be nice to have a helper for that and raise a |
I'm still struggling with how to mitigate strict exception groups within the trio libraries I maintain. The worst thing is that I can't declare a |
I haven't seen any reference of explicitly setting I don't maintain a library that uses trio so if it seems like I'm missing something, I probably am :P |
I don't know how far you'd get, as there may be 3rd party things your code calls (within trio API itself or utility libs) that wrap nursery and don't give you access to the option. |
Follow-up for #2886 (comment):
We should also skim through other mentions of
ExceptionGroup
to ensure that our messaging is consistent across all the docs.The text was updated successfully, but these errors were encountered: