On 2020-04-10 7:05 a.m., Greg Ewing wrote:
On 10/04/20 8:30 am, Soni L. wrote:
Sometimes, you have an API:
@abc.abstractmethod def get_property_value(self, prop): """Returns the value associated with the given property.
Args: prop (DataProperty): The property.
Returns: The value associated with the given property.
Raises: PropertyError: If the property is not supported by this config source. LookupError: If the property is supported, but isn't available. ValueError: If the property doesn't have exactly one value. """ raise PropertyError
This doesn't really look like a Python API. It's fairly rare in Python for exceptions to be used to indicate anything other than "something unexpected went wrong".
In your unpacking example, the ValueError isn't really intended as something to be caught under normal circumstances. The assumption is that you'll know how many items to expect when you unpack something, and if you don't get that many, then you have a bug.
You could advocate for unpacking to use a more specific exception to facilitate catching it, but I think most people will consider your use case to be quite rare.
so my proposal is that we get "exception spaces". they'd be used through the 'in' keyword, as in "except in" and "raise in".
I don't think exceptions are used this way in Python commonly enough to justify this.
it's actually fairly common to deal with KeyError instead of using dict.get or w/e.
KeyError is also raised when your code has a bug and your assumptions got broken.
it's fairly easy to get the two different KeyErrors mixed up, at least. idk if this is the case for other exception types, but I'd expect a few other exception types might also commonly be used in this way.