-
Notifications
You must be signed in to change notification settings - Fork 273
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
Add exception handling guidelines #1131
Comments
See related #967 |
I'm not sure if it's deserving of a separate label, but we should make it clear that the result of every discussion should be documented. Whether a decision record, contributor guideline or some other form. |
Good point @MVrachev. But how would the decision record about exception guidelines differ from the exception guideline document itself? I think the reason why I didn't use the label here is because I envisioned the guideline document itself a good central place that justifies the way exceptions are handled in multiple places, and probably this issue page as easily identifiable place to look up any additional discussion, that are not part of the guideline document. That said, I do see how it's not always clear if something classifies for a decision record or not. A general rule of thumb to classify something could be: "The decision is worth being tracked and there is no easily identifiable place (e.g. PR or issue page, commit message, code comment, other documentation or guideline, etc...) for it to be tracked at." What do you think? At any rate, we should make this clear as part of #1141. |
Which exceptions should be handled, which exceptions should be propagated to the user? When should we use custom exceptions, when should we use built-in exceptions? etc...
The Google Python style-guide has some reasonable suggestions about exceptions.
The text was updated successfully, but these errors were encountered: