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
Add an HPX_ALWAYS_ASSERT macro #628
Comments
It might be better for you, but there would be no way for application programmers to handle such problems programmatically. I wouldn't like to weaken the error handling capabilities we have. What you could do, though, is to add a (non-default) compile time option inserting a hard break into the function |
Hartmut, assertions get turned into exceptions anyways. BOOST_ASSERT throws an hpx exception... |
Can we discuss this a little further? |
I really hope that's not the case! And from looking at the code I can tell it is not throwing an exception. |
What would you like to discuss? Error handling using exceptions is conceptually totally different from assertions. Exceptions signal problems raised by failures which could be caused by wrong user input or other unexpected external (to the program) events. An application might want to handle those errors and react gracefully (or not). Assertions are constructs enforcing pre- or postconditions for a function or module. I would not like to raise an assertion whenever an exception is to be thrown by default. But as I said, go ahead, add a (non-default) compilation option with some obscure name (something like |
Sorry, I didn't actually mean to reopen this, just wanted to talk about this more. |
I think it might be a good idea to have an HPX_ALWAYS_ASSERT macro, for assertions
that we want to show up in release mode. Personally, I find assertions quicker to
write than throwing an HPX exception. With an HPX exception, I have to check for the
error condition, choose an error code and specify the function that I'm in. For low-level
sanity checks, assertions might be a better mechanism to use, as we are more likely
to use more of them if they are quicker to write.
The text was updated successfully, but these errors were encountered: