If I use assert()
and the assertion fails then assert()
will call abort()
, ending the running program abruptly. I can't afford that in my production code. Is there a way to assert in runtime yet be able to catch failed assertions so I have the chance to handle them gracefully?
相关问题
- Sorting 3 numbers without branching [closed]
- How to compile C++ code in GDB?
- Why does const allow implicit conversion of refere
- thread_local variables initialization
- What uses more memory in c++? An 2 ints or 2 funct
相关文章
- Class layout in C++: Why are members sometimes ord
- How to mock methods return object with deleted cop
- Which is the best way to multiply a large and spar
- C++ default constructor does not initialize pointe
- Selecting only the first few characters in a strin
- What exactly do pointers store? (C++)
- Converting glm::lookat matrix to quaternion and ba
- What is the correct way to declare and use a FILE
If you want to throw a character string with information about the assertion: http://xll8.codeplex.com/SourceControl/latest#xll/ensure.h
Asserts in C/C++ only run in debug builds. So this won't happen at runtime. In general asserts should mark things that if they happen indicate a bug, and generally show assumptions in your code etc.
If you want to have code that checks for errors at runtime (in release) you should probably use exceptions rather than asserts as these are what they are designed to do. Your answer basically wraps an exception thrower in assert syntax. While this will work, there is no particular advantage to this that I can see over just throwing the exception in the first place.
Here's what I have my in "assert.h" (Mac OS 10.4):
Based on that, replace the call to abort() by a throw( exception ). And instead of printf you can format the string into the exception's error message. In the end, you get something like this:
I haven't tried to compile it, but you get the meaning.
Note: you'll need to make sure that the "exception" header is always included, as well as boost's (if you decide to use it for formatting the error message). But you can also make "my_assert" a function and only declare its prototype. Something like:
And implement it somewhere where you can freely include all the headers you require.
Wrap it in some #ifdef DEBUG if you need it, or not if you always want to run those checks.
glib's error reporting functions take the approach of continuing after an assert. glib is the underlying platform independence library that Gnome (via GTK) uses. Here's a macro that checks a precondition and prints a stack trace if the precondition fails.
Here's the function that prints the stack trace, written for an environment that uses the gnu toolchain (gcc):
This is how you'd use the macros:
Yes, as a matter of fact there is. You will need to write a custom assert function yourself, as C++'s
assert()
is exactly C'sassert()
, with theabort()
"feature" bundled in. Fortunately, this is surprisingly straightforward.Assert.hh
The above function will throw an exception if a predicate doesn't hold. You will then have the chance to catch the exception. If you don't catch the exception,
terminate()
will be called, which will end the program similarly toabort()
.You may wonder what about optimizing away the assertion when we're building for production. In this case, you can define constants that will signify that you're building for production and then refer to the constant when you
Assert()
.debug.hh
main.cc
If
CHECK_WRONG
is a constant then the call toAssert()
will be compiled away in production, even if the assertion is not a constant expression. There is a slight disadvantage in that by referring toCHECK_WRONG
we type a little more. But in exchange we gain an advantage in that we can classify various groups of assertions and enable and disable each of them as we see fit. So, for example we could define a group of assertions that we want enabled even in production code, and then define a group of assertions that we only want to see in development builds.The
Assert()
function is equivalent to typingbut it clearly indicates the intent of the programmer: make an assertion. Assertions are also easier to grep for with this approach, just like plain
assert()
s.For more details on this technique see Bjarne Stroustrup's The C++ Programming Language 3e, section 24.3.7.2.
believe me, this function can help you.