Change the contract of get_typesupport_handle_function.#102
Draft
clalancette wants to merge 1 commit intorollingfrom
Draft
Change the contract of get_typesupport_handle_function.#102clalancette wants to merge 1 commit intorollingfrom
clalancette wants to merge 1 commit intorollingfrom
Conversation
Before it would set an RCUTILS error if the typesupport didn't match. But because this is essentially a probe, we change it to not set that on error and instead just return a nullptr. Callers can disambiguate between the probe not finding a typesupport and a real error by checking the return value for nullptr and then checking if `rcutils_error_is_set`. Signed-off-by: Chris Lalancette <clalancette@openrobotics.org>
Contributor
Author
|
Full CI:
|
sloretz
reviewed
Jan 11, 2021
Contributor
sloretz
left a comment
There was a problem hiding this comment.
The change to not set an error seems fine, though it's hard to judge because the purpose of the existing code is not clear to me.
The unrelated change to the first conditional change seems fine, but it makes the diff pretty hard to follow.
| std::string library_name; | ||
| try { | ||
| library_name = rcpputils::get_platform_library_name(library_basename); | ||
| } catch (const std::runtime_error & e) { |
Contributor
There was a problem hiding this comment.
Assuming exception -> runtime_error change is due to:
| "Could not load library %s: %s", library_name.c_str(), e.what()); | ||
| return nullptr; | ||
| } | ||
| map->data[i] = lib; |
Contributor
There was a problem hiding this comment.
Any explanation of how this code works that you're aware of? It's a little strange that it modifies a non-const void ** member of a const type_support_t *.
Contributor
Author
There was a problem hiding this comment.
Honestly, I just moved it around. @hidmic was involved in the latest rewrite of it, I believe. Maybe he can shed some light.
This was referenced Apr 2, 2021
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Before it would set an RCUTILS error if the typesupport
didn't match. But because this is essentially a probe, we
change it to not set that on error and instead just return
a nullptr. Callers can disambiguate between the probe not
finding a typesupport and a real error by checking the return
value for nullptr and then checking if
rcutils_error_is_set.Signed-off-by: Chris Lalancette clalancette@openrobotics.org
I went ahead and checked all of the callers of these functions that I could find, and as far as I can tell all of them will be OK with this change. There may be some additional tests that are expecting the old error; besides the ones I fixed here, I didn't find any additional ones. But I didn't run them all, so the full CI run should help track that down.
This change should help resolve some of the errors on CentOS that occurred in CI in combination with ros2/rmw#293 . This is still a draft PR since I'm not 100% sure we want to do this; opinions welcome.
If we merge this, this will fix #100