-
Notifications
You must be signed in to change notification settings - Fork 120
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
Logging output when using fatal assertions #380
Comments
Sorry for the late response. I wasn't sure what should be done about it but after some thinking, I get into the conclusion that we don't wanna print in all cases and hence it's better not to print it all not to confuse the users 🤔 But I'm happy to be To illustrate what I'm talking about let's magine the case that after the fatal assertion we will try to print out range value - that would sig segv 😞 std::vector v{1, 2, 3};
(std::size(v) == 3_i >> fatal) << "incorrect" << v[4]; |
Wouldn't that be an issue even if the assertion was not fatal or am I missing something? |
Yes, it would but that's why you would use a fatal assertion to avoid it, right? |
Aww, I see what you mean. What if a user wants helpful error information when a fatal assertion occurs? This is my use case. |
I understand the use case (which is obviously a valid one) just have concerns that by allowing streaming anything after fatal assertion the guarantee that the assertion will bail out and won't crash (the main purpose of it) may be broken. It's not an issue if you just print a string or something but it might be if a value out of range will be tried to be accessed. We potentially can allow just |
This appears to come down to a ease-of-use / safety problem. A user could just workaround this situation by using an
std::vector v{1, 2, 3};
(std::size(v) == 2_i >> fatal) << "Surprised?";
std::vector v{1, 2, 3};
(std::size(v) == 3_i >> fatal) << "I like to play it safe." << v[4];
std::vector v{1, 2, 3};
(std::size(v) == 3_i >> fatal) << "I swear I know what I'm doing!" << unsafe << v[4]; |
I don't understand the concern. The message will only be printed in the case that the assertion fails, right? So using the assertion to guard against some unsafe behavior in the message seems very strange. |
Example
A fatal assertion with logged output for failure.
Expected Behavior
When the assertion fails, "Incorrect!" should be printed.
FAILED [false] Incorrect!
Actual Behavior
When the assertion fails, "Incorrect!" is not printed.
FAILED [false]
Steps to Reproduce the Problem
Specifications
The text was updated successfully, but these errors were encountered: