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

ASSERT or variant returning result of the expression (not just left-hand operand) #101

Open
StenSoft opened this issue Aug 22, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@StenSoft
Copy link

Hi,

One thing that I currently use pretty often (especially for networking code) is:

if (!AssertTrue(a > 3)) {
    // Handle the failed assertion in release
    return;
}

This allows crashing in debug builds during testing but handling it without crashing for users in release builds.

It looks very similar to:

if (!ASSERT_VAL(a > 3))

but ASSERT_VAL returns the value of a, not the result of the whole expression a > 3.

Obviously it's possible to do

if (ASSERT_VAL(a > 3) <= 3)

but that makes it complicated and error-prone.

Would it be possible to return the result of the whole expression from ASSERT, or to create a variant of the macro (e.g. ASSERT_THAT) that returns the result?

@jeremy-rifkin
Copy link
Owner

Thanks for opening this,
One thing I'm thinking about here is the line is between assertions and error handling. Generally assertions should be used for preconditions/postconditions, where violation constitutes a logical error from which execution cannot safely proceed. In this case and the #100 issue it looks like execution is possible after the condition violation.

I'd be interested in your thoughts.

I definitely agree on if (ASSERT_VAL(a > 3) <= 3) not being ideal.

@StenSoft
Copy link
Author

My code runs distributed on many nodes in a network. In debug (or checked) builds, I want to make it obvious when there's a communication problem which should never happen in correct code and on reliable network but in release builds, I want it to be able to handle any data so that network problems or crashes of some devices (or malicious actors) won't bring the whole network down. I guess this is still error handling, not assertions (the node itself can recover), but error handling that in debug builds behaves just like failed assertions and produces core dumps so that the exact state can be analysed in detail, and in release build optimises the code so that the failure paths are marked [[unlikely]] (or __builtin_expect(…, false)) and logged with all the details that libassert can provide.

@jeremy-rifkin jeremy-rifkin added the enhancement New feature or request label Sep 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants