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.
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
Ensure compliant publisher API. #414
Ensure compliant publisher API. #414
Changes from 3 commits
f62b9fd
86504c8
cd3c9af
66bf068
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I don't like having to do this to ensure the first error that occurs is the one that pops up and that no subsequent error goes unnoticed.
If we had a way to tell
rcutils
that we're in error handling or finalization/cleanup mode so that it doesn't complain about error states being overwritten (and prints the new one tostderr
, or aborts the program, or whatever), this code would simpler (and a bit more neat). What do reviewers think?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.
same comment than in the
rmw_cyclonedds
PR.I think that for destruction, logging everywhere and setting a generic error message at the end if an error happened might be the simpler approach.
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.
That'd be simpler, yeah, but I think we would be trading usability in the process. To the point it makes me wonder what 's the point of returning an generic error code vs. not returning anything.
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.
I agree that this is a bit unfortunate. The big problem is that you have to be careful on every error path to do the checking and not overwrite the error. It will always be a game of whack-a-mole (or we have to have really good tests).
To be fair, the generic error code at least distinguishes between "succeeded" and "failed". The question on whether the individual errors are worthwhile comes down to whether the calling code can do anything reasonable in response to the error. If that caller can do something specific in response to some errors, then it makes sense to have individual errors. If the caller can never do anything about the situation, the generic error is enough.
The problem in my mind with the
rcutils
flag is that it is not generic enough; you also need that flag at the rcl layer, rmw layer, and potentially the rclcpp/rclpy layers as well.Overall, I think the error situation isn't perfect. But I also think it is a large topic, and we don't necessarily have to solve it here. I'd say that we continue with this PR assuming the current situation. We can open up a separate issue and potentially have a meeting where we talk about the broader issue of errors. Does that sound reasonable?
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.
True, but we don't need specific return codes for that.
Why? It's the same flag everywhere. It doesn't have to be a flag either, it's just that building anything bigger than this seems overkill.
Fair enough. Let's roll as-is.
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.
I'm thinking of this situation:
But its possible that I don't have enough context on how the error handling works.
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.
So, all layers use the same thread local error state and API that's defined in
rcutils
but through aliases. In your example,rcl_do_thing
would enter this error handling mode for the extent of thatif
block statement. In a way, it's a poor man's try-catch block.But I see now that arbitrarily nested error handling may occur (a try-catch in the catch block of a try-catch in the catch block of...). We would have to make it reentrant and a boolean flag isn't enough. An integer count could be used instead.