-
-
Notifications
You must be signed in to change notification settings - Fork 6.8k
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
Coverity Scan reports an UNCAUGHT_EXCEPT issue #1400
Comments
I think such an exception cannot occur - at least not in the case of range-for. I am wondering whether it would make sense to try to (1) silence this issue, (2) somehow cope with the exception, or (3) just remove the |
Unless there is a way to prevent these from being called from outside range-for, then I don't think they can be noexcept, unless you first test that Since |
In general, we may have to discuss the design decision in case of a violated precondition. Comparing iterators of different containers is, to my knowledge, undefined behavior. There are some choices to implement the comparison:
While (1) is the safest approach, (2) and (3) would have the benefit of being What do you think? |
Any idea? |
Coverity Scan reports an
UNCAUGHT_EXCEPT
issue.No. Instead here is the report:
No reported issue.
Reported issue.
N/A
develop
branch?develop
/ 3.5.0 release.N/A
The problem is that the
iteration_proxy_value
class's comparison operators are markednoexcept
. They are implemented by the underlying iterator class's comparison operators which may throwjson::invalid_iterator
when iterators of different JSON values are compared. Coverity Scan warns that if such an exception is thrown, the program would terminate.The text was updated successfully, but these errors were encountered: