-
-
Notifications
You must be signed in to change notification settings - Fork 398
Review exceptions #830
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
Comments
Sounds good to me.
There's some precedent in Python's standard library for exceptions with multiple base classes, see this post: https://www.reddit.com/r/Python/comments/1k9ygb/multiple_inheritance_for_library_exceptions/ So maybe it's not necessarily a bad thing that needs to be removed in the future. |
yes you're right, it may be a good thing |
While I implemented a first version there are currently some reasons that stop us from fully switching to such a system that will probably need to be tackled one-by-one.
|
To have one exception for every
GIT_EXXX
all of them inheriting fromGitError
, use a consistent naming, e.g.GIT_EINVALIDSPEC
would becomeGitInvalidSpecError
or maybe justInvalidSpecError
.To provide backwards compatibility use multiple inheritance, e.g.
InvalidSpecError
would inherit fromGitError
andValueError
. Eventually the base class for backwards compatibility would be remove in some future version.To settle on naming post here the full mapping of
GIT_EXXX
to exception, even if this can be implemented in steps.This follows up on issues #531 and #828
The text was updated successfully, but these errors were encountered: