Skip to content
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

Exception objects must be nothrow copy constructible (ERR60-CPP) #531

Closed
nlohmann opened this issue Mar 23, 2017 · 4 comments
Closed

Exception objects must be nothrow copy constructible (ERR60-CPP) #531

nlohmann opened this issue Mar 23, 2017 · 4 comments

Comments

@nlohmann
Copy link
Owner

The SEI CERT C++ Coding Standard states in ERR60-CPP:

If the copy constructor for the exception object type throws during the copy initialization, std::terminate() is called, which can result in undefined behavior.

The user-defined exceptions all base on detail::exception which has a std::string member. The exceptions have to be refactored to satisfy std::is_nothrow_copy_constructible.

@jaredgrubb
Copy link
Contributor

Std::string would only throw if you run out of memory, right? The exceptions you're discussing would have strings that have ~100 bytes in them. If you run out of memory over 100 bytes, I dont think anyone actually expects to recover from that.

I agree that this is a good goal, but personally, I treat things like std::string as effectively no-throw because there's no chance a program can recover from extreme low-memory like that.

@nlohmann
Copy link
Owner Author

I agree that this is not a major issue. I just wanted to document it and maybe add more problems later. The document also proposes a fix I have not tried yet.

@nlohmann
Copy link
Owner Author

nlohmann added a commit that referenced this issue Mar 25, 2017
To have nothrow-copy-constructible exceptions, we inherit from
std::runtime_error which can cope with arbitrary-length error messages.
Intermediate strings are built with static functions and then passed to
the actual constructor.
@nlohmann nlohmann self-assigned this Mar 25, 2017
@nlohmann nlohmann added kind: enhancement/improvement solution: proposed fix a fix for the issue has been proposed and waits for confirmation labels Mar 25, 2017
@nlohmann nlohmann added this to the Release 3.0.0 milestone Mar 25, 2017
@nlohmann
Copy link
Owner Author

The issue can be fixed by storing the message inside a std::runtime_exception object. Then, our exceptions are nothrow copy constructible if std::runtime_exception is.

The fix 53b501a can be merged when the CI builds complete.

@nlohmann nlohmann removed the solution: proposed fix a fix for the issue has been proposed and waits for confirmation label Apr 7, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants