Skip to content

Build: Fix exceptions #10616

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

Merged
merged 4 commits into from
Aug 10, 2023
Merged

Build: Fix exceptions #10616

merged 4 commits into from
Aug 10, 2023

Conversation

stsewd
Copy link
Member

@stsewd stsewd commented Aug 8, 2023

We were passing the path to the constructor,
but that argument is actually the message.

The message is already defined in the exception itself.

Fixes #10538

We were passing the path to the constructor,
but that argument is actually the message.

The message is already defined in the exception itself.
@stsewd stsewd requested a review from a team as a code owner August 8, 2023 21:07
@stsewd stsewd requested a review from humitos August 8, 2023 21:07
Copy link
Member

@humitos humitos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We were passing the path to the constructor, but that argument is actually the message.

What about checking the message= type is string in the initializer?

class BuildBaseException(Exception):
message = None
status_code = None
def __init__(self, message=None, **kwargs):
self.status_code = kwargs.pop(
'status_code',
None,
) or self.status_code or 1
self.message = message or self.message or self.get_default_message()
super().__init__(message, **kwargs)

Or, cast it into string?

I'm thinking about a way to avoid this issue since we've hit long time ago and it was hard to track. I remember talking to Anthony about this and we weren't able to figure it out what was happening.

@stsewd
Copy link
Member Author

stsewd commented Aug 9, 2023

What about checking the message= type is string in the initializer? Or, cast it into string?

Do you mean raising an exception if the type is incorrect? I'm +1 on that instead of casting, since looks like most of the time, passing that argument to exceptions that have an already defined default message is a mistake.

@stsewd
Copy link
Member Author

stsewd commented Aug 10, 2023

Didn't find any other exceptions where we were overriding the default message like this.

@stsewd stsewd merged commit e766968 into main Aug 10, 2023
@stsewd stsewd deleted the fix-exceptions branch August 10, 2023 18:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Bad Sphinx configuration path causes uncaught error while updating the build through API
2 participants