Skip to content

Add missing error handling to module_::def_submodule #3973

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
May 28, 2022

Conversation

rwgk
Copy link
Collaborator

@rwgk rwgk commented May 26, 2022

Description

Extracted from PR #3964, where the missing error handling happened to cause some confusion.

Suggested changelog entry:

``module_::def_submodule`` was missing proper error handling. This is fixed now.

@rwgk rwgk marked this pull request as ready for review May 26, 2022 11:14
@rwgk rwgk requested a review from Skylion007 May 26, 2022 11:14
if (this_name == nullptr) {
throw error_already_set();
}
std::string full_name = std::string(this_name) + "." + name;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
std::string full_name = std::string(this_name) + "." + name;
std::string full_name = std::string(this_name) + '.' + name;

if (!submodule) {
throw error_already_set();
}
auto result = reinterpret_borrow<module_>(submodule);
Copy link
Collaborator

Choose a reason for hiding this comment

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

For reference, wouldn't you also been able to do?

if(!result){
            throw error_already_set();
}

This looks good either way though.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

IIU your question correctly, that would assume reinterpret_borrow<module_> is OK with nullptr, and does not care about the active error. While that is usually true, what if someone temporarily adds debugging code to reinterpret_borrow, or the module_ constructor in this case? Their fault, of course, but why build a trap like that?
Generally, I think it is bad style to separate error handling from the source of the error more than necessary.

Copy link
Collaborator

@Skylion007 Skylion007 left a comment

Choose a reason for hiding this comment

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

Approve with minor nit: (Append a char instead of a 1char string literal, it's a faster overload.)

@rwgk rwgk force-pushed the def_submodule_error_handling branch from b8a16e3 to dbbe9d1 Compare May 28, 2022 19:07
@rwgk rwgk merged commit 748ae22 into pybind:master May 28, 2022
@rwgk rwgk deleted the def_submodule_error_handling branch May 28, 2022 23:41
@github-actions github-actions bot added the needs changelog Possibly needs a changelog entry label May 28, 2022
@henryiii henryiii removed the needs changelog Possibly needs a changelog entry label Jul 7, 2022
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.

3 participants