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: