Remove unnecessary asserts #4
Open
Conversation
This file contains 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
There are two acknowledged exception cases, which are handled inside falcolibs, but contain an unconditional ASSERT. One happens when reading information about the cgroup for the process (the process can disappear in the meantime, leaving the library failing on trying to open a corresponding procfs entries), another one at reading information about the process itself (the same story, the process can be already finished at this point, leaving no procfs entries). Both errors are valid from the design point of view, and they do not represent any significant issue, so it doesn't make sense to throw an ASSERT in the debug mode. Note, that there are more `ASSERTS(false)`, but only those two are proven to be fine to remove at the moment.
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.
There are two acknowledged exception cases, which are handled inside
falcolibs, but contain an unconditional ASSERT. One happens when reading
information about the cgroup for the process (the process can disappear
in the meantime, leaving the library failing on trying to open a
corresponding procfs entries), another one at reading information about
the process itself (the same story, the process can be already finished
at this point, leaving no procfs entries).
Both errors are valid from the design point of view, and they do not
represent any significant issue, so it doesn't make sense to throw an
ASSERT in the debug mode. Note, that there are more
ASSERTS(false),but only those two are proven to be fine to remove at the moment.