-
-
Notifications
You must be signed in to change notification settings - Fork 344
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
Finalize exception names: BrokenResourceError? BusyResourceError? #620
Comments
Yep, I'd rename it.
I generally design exceptions by asking "what will users want to catch", so why not both? That is, define The argument for |
You meant this rhetorically, but there actually is an answer :-). Example: suppose we have a "channel" object (#586) that's implemented on top of a Now, while that's happening in one task, another task calls
Also, this example with channels on top of streams has kind of convinced me that we should have a single |
- Rename BrokenStreamError to BrokenResourceError - Rename ResourceBusyError to BusyResourceError Fixes python-triogh-620 (and see there for the rationale).
- Rename BrokenStreamError to BrokenResourceError - Rename ResourceBusyError to BusyResourceError Fixes python-triogh-620 (and see there for the rationale).
This isn't super urgent, but I want to make sure we revisit it before v1.0, so creating an issue that I can tag "potential API breaker".
Should we rename
ResourceBusyError
→BusyResourceError
, for consistency withClosedResourceError
(and so the most meaningful part of the name come first)? Probably.Should we consolidate
BrokenStreamError
,BrokenChannelError
, etc., into a genericBrokenResourceError
, like we did withClosedResourceError
andResourceBusyError
? Not sure. Maybe. The other ones it was mandatory because these exceptions passed between levels (e.g. socket -> stream). For theBroken
family this isn't as likely, so we have the curse of options.The text was updated successfully, but these errors were encountered: