-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Rename exceptions #6539
Rename exceptions #6539
Conversation
85fd69b
to
3cb7cbe
Compare
Thank you for your pull request! We could not find a changelog entry for this change. For details on how to document a change, see the contributing guide. |
do people rely on these exceptions? Is it worth making this change just to comply with pep style guide? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow. So many lines changed... But consistency is a good thing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have a sense on the broader impact this will have? Could this break services invoking us programmatically?
@colin-rogers-dbt the old exceptions have been deprecated, not yet removed. So this should not break anyone immediately. We also do not currently guarantee this as an interface. And the conversations I've had internally seem to point to only using RPC exceptions which I did not touch. Only 22 of the renamed exception existed before 1.4 and those are the ones deprecated. The rest are ones I created in a previous PR while deprecating our exception functions. |
b26b12b
to
ee154f0
Compare
@colin-rogers-dbt and i had a conversation offline and decided to remove the deprecations on the classes. Leaving them deprecated has the potential to introduce bugs into adapters if they are catching specific exceptions. They will never catch the old exception, but because the class still exists they will also not break. While removing the old classes entirely will break anyone referring to the old exception classes, it will also prevent any silent bugs. |
### Description Follows up on renaming exceptions. - dbt-labs/dbt-core#6539 - dbt-labs/dbt-spark#585
Some are certainly in use, e.g. see sqlfluff/sqlfluff#4325. Removing deprecated stuff seems reasonable, but it does seem like something you'd want to do in a major release. For others running into this, it seems like 1.3.x is the last before this breaking change. |
rename error class by dbt-labs/dbt-core#6539
resolves #6460
Description
Standardized exception classes to end in
Error
to meet PEP recommendations here.Checklist
changie new
to create a changelog entry