-
-
Notifications
You must be signed in to change notification settings - Fork 366
Description
We currently have some exceptions that take multiple parameters and use them to generated a pre-formatted exception:
class BaseZarrError(ValueError):
"""
Base error which all zarr errors are sub-classed from.
"""
_msg = ""
def __init__(self, *args: Any) -> None:
super().__init__(self._msg.format(*args))
class ContainsGroupError(BaseZarrError):
"""Raised when a group already exists at a certain path."""
_msg = "A group exists in store {!r} at path {!r}."
ContainsGroupError('a','b')
# ContainsGroupError("A group exists in store 'a' at path 'b'.")I think this is kind of pointless, because outside of our tests we are not programmatically parsing the string contents of exception messages, and it's also confusing for developers because we don't document these parameters on the exception classes, and normal python exceptions don't (to my knowledge) require multiple arguments that go into a templated string.
Since IMO this pre-formatting is of negative value, I propose deprecating it. To make this smooth, creating an exception with a single argument will treat that as a pre-formatted string (i.e., normal python exception behavior). For exceptions that previously performed special formatting, this will be triggered by creating the exception with multiple arguments.
I don't know how to deprecate this "noisily" -- emitting a deprecation warning when an exception is raised doesn't really reach the right audience, and I don't know how to issue a developer-targeted deprecation warning for a specific form of object construction. Happy to hear other ideas here.