What is the best way of implementing assertion che

Question

By that I mean, what do I need to do to have useful assertions in my code?

MFC is quite easy, i just use ASSERT(something).

What's the non-MFC way?

Edit: Is it possible to stop assert breaking in assert.c rather than than my file which called assert()?

Edit: What's the difference between <assert.h> & <cassert>?

Accepted Answer: Loads of great answers in this post, I wish I could accept more than one answer (or someone would combine them all). So answer gets awarded to Ferruccio (for first answer).

Answer 1

To break inside the file that called the assert, you can use a custom macro that throws an exception or calls __debugbreak:

#define MYASSERT(EXPR, MSG) if (!(EXPR)) throw MSG;

Or:

#define MYASSERT(EXPR) if (!(EXPR)) __debugbreak();

Answer 2

Assert is (usually) Debug Only

The problem with "assert" is that it is usually in debug binaries, and that some developers use them as if the code would still be in production.

This is not evil per se, as the code is supposed to be intensively tested, and thus, the bugs producing the assert will surely be discovered, and removed.

But sometimes (most of the times?), the tests are not as intensive as wanted. I won't speak about an old job where we had to code until the very last minute (don't asks... Sometimes, managers are just... Ahem...)... What's the point of an assert you adding to a code that will be compiled and delivered as a Release Binary to the client the next minute?

Assert in (some) real life applications

In our team, we needed something to detect the error, and at the same time something else to handle the error. And we needed it, potentially, on Release Build.

Assert will both detect and handle the error only on debug build.

So we added instead a XXX_ASSERT macro, as well as a XXX_RAISE_ERROR macro.

The XXX_ASSERT macro would do the same thing as the ASSERT macro, but it would be built both in Debug and in Release. Its behaviour (write a log, open a messagebox, do nothing, etc.) could be controlled by a .INI file, and THEN, it would abort/exit the application.

This was used as:

bool doSomething(MyObject * p)
{
   // If p is NULL, then the app will abort/exit
   XXX_ASSERT((p != NULL), "Hey ! p is NULL !") ;

   // etc.
}

XXX_RAISE_ERROR macro would only "log" the error but would not try to handle it. This means that it could log the message in a file and/or open a MessageBox with the message , and a button to continue, and another to launch a debug session (as per .INI file config). This was used as:

bool doSomething(MyObject * p)
{
   if(p == NULL)
   {
      // First, XXX_RAISE_ERROR will alert the user as configured in the INI file
      // perhaps even offering to open a debug session
      XXX_RAISE_ERROR("Hey ! p is NULL !") ;
      // here, you can handle the error as you wish
      // Than means allocating p, or throwing an exception, or
      // returning false, etc.
      // Whereas the XXX_ASSERT could simply crash.
   }

   // etc.
}

One year after their introduction in our libs, only XXX_RAISE_ERROR is being used. Of course, it can't be used on time-critical parts of the app (we have a XXX_RAISE_ERROR_DBG for that), but everywhere else, it is good. And the facts that one can use whatever prefered error handling, and that it can be activated at will, either on the developer computer, or the tester, or even the user, is quite useful.

Answer 3

To answer the question in your second "edit":

< assert.h> is the C header

< cassert> is the C++ Standard Library header ... it typically includes < assert.h>

Answer 4

use intellisense to open it in visual studio (right click)

// cassert standard header
#include <yvals.h>
#include <assert.h>

yvals.h is windows stuff. so, as far as assert() itself is concerned, the two ways to include it are identical. it's good practice to use the <cxxx> because often it isn't that simple (namespace wrapping and maybe other magic)

This breaks at caller site for me...

here's an article explaining why you don't want to write this macro yourself.

Answer 5

To answer the asker's third question: the first reason we use "cassert" instead of "assert.h" is because, in the case of C++, there's an allowance made for the fact that the C++ compiler may not store the function descriptions in code files, but in a dll or in the compiler itself. The second is that there may be minor changes made to functions in order to facilitate the differences between C and C++, either present or in the future. Because assert.h is a C library, the preference is to use "cassert" while in C++.

Answer 6

It depends on whether or not you are looking for something that works outside of Visual C++. It also depends on what type of assertion you are looking for.

There are a few types of assertions:

1. Preprocessor
   These assertions are done using the preprocessor directive #error
   Preprocessor assertions are only evaluated during the preprocessing phase, and therefore are not useful for things such as templates.

2. Execute Time
   These assertions are done using the assert() function defined in <cassert>
   Execute time assertions are only evaluated at run-time. And as BoltBait pointed out, are not compiled in if the NDEBUG macro has been defined.

3. Static
   These assertions are done, as you said, by using the ASSERT() macro, but only if you are using MFC. I do not know of another way to do static assertions that is part of the C/C++ standard, however, the Boost library offers another solution: static_assert.
   The static_assert function from the Boost library is something that is going to be added in the C++0x standard.

As an additional warning, the assert() function that Ferruccio suggested does not have the same behavior as the MFC ASSERT() macro. The former is an execute time assertion, while the later is a static assertion.

I hope this helps!