-
Notifications
You must be signed in to change notification settings - Fork 1.5k
fixed missing exception handling in MathLib::toBig{U}Number()
#8025
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
base: main
Are you sure you want to change the base?
Conversation
|
|
Uncovered by adding |
| try { | ||
| return simplecpp::characterLiteralToLL(str); | ||
| } catch (const std::exception& e) { | ||
| } catch (const std::runtime_error& e) { |
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.
why? if there is some c++ exception it sounds good to handle that?
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.
Using std::exception might imply it might throw more than a specific type which is not the case.
It is also better to have narrow exceptions (IMO - also a best practice in Java/Python - which have better annotations to be fair).
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.
Using std::exception might imply it might throw more than a specific type which is not the case.
I fear you only looked at what exceptions the functions are throwing explicitly.
It is also better to have narrow exceptions (IMO - also a best practice in Java/Python - which have better annotations to be fair).
Imho it's a bad idea in Python to catch generic Exception because that will catch everything including when Ctrl+C is pressed. Yes it can be too broad.
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.
If your intention is: "if there is a C++ exception here then you want it to be catched in the CppCheck instead of throwing an InternalError" then this would be the proper change. But I wouldn't see the point of that.
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 fear you only looked at what exceptions the functions are throwing explicitly.
That's how we treat exceptions.
If your intention is: "if there is a C++ exception here then you want it to be catched in the CppCheck instead of throwing an InternalError" then this would be the proper change. But I wouldn't see the point of that.
It was inconsistent and the InternalError also takes the token so if we were encountering this exception the location which caused it would have been missing.
I will noexcept the simplecpp interface in a follow-up (still waiting for llvm/llvm-project#168324 to be merged).
This is also the only function which currently throws and for consistency we should probably adjust that - but that is something for the future.



No description provided.