views:

90

answers:

1

To think ... there I have been happily programming in an MFC riddled environment for years, using ASSERT() whenever it seemed OK and just today I (was) stumbled upon the VERIFY Macro: http://msdn.microsoft.com/en-us/library/fcatwy09%28v=VS.71%29.aspx

It's basically the same as ASSERT() except the expression will not be removed in release builds (the check will, but the expression will still be evaluated).

#ifdef _DEBUG
#define VERIFY(f)          ASSERT(f)
#else   // _DEBUG
#define VERIFY(f)          ((void)(f))

I can see a few uses for it, but I was wondering if others use it regularly in their code base and if anyone has seen any adverse side effects of using it.

cheers.

+1  A: 

When I used to do MFC programming, I used it all the time.

Basically everything which returns something that I'm normally too lazy to check the return from, but which Lint then whines at you about, I would wrap in a VERIFY. (Calls like ::CloseHandle, for example)

There cannot be any adverse side effects to using it in a released product, because it's a no-op on a release build anyway.

Will Dean
Another question is if we should have return values in the program that we are 'too lazy to check'. ::CloseHandle is a good example though.
Martin