[RESOLVED] Assertions

[logan]

Hi,

Steve Maguire in Writing Solid Code mentions how his re-write of an old library, which previously had no assertions, caused so many assertion errors in the code that now used the new library.

How can adding assertions to my code help discover otherwise unfound bugs? If my code is running fine then it means that I have checked for invalid parameters to functions and other stuff like that. Then how do assertions are supposed to help?

void foo (HWND hWnd)
{
	ASSERT (::IsWindow (hWnd));
	//Do something with hWnd
}

Now in release build the ASSERT will be removed, so how can I be so sure that an invalid handle won't be passed any other time?

Won't it be better to do something like this:

void foo (HWND hWnd)
{
	ASSERT (hWnd);
	if (!hWnd)
		return;
	...
}

So what I think is that assertions only notify you of problems and prevents me from stepping into the code. Is this correct? Or I'm missing something?

Thanks.

[S_M_A]

I use asserts for checking that interface limits are fulfilled and that my "in the middle of code" assumptions are correct.

Ex. let's say you write a function:

uint32 FromInputReturnMagicResult( uint32 a, int32 b );

In the documentation you clearly state that a <= 1000000 and b < 0. You can of course hardcode a test for this and show a messagebox or whatever, or you can state that on error function returns an invalid magic result.

For all situations in a properly coded application though you know that this type of error will never occur so why having code that never should be executed? That code only clutters the files and make them harder to read.

Instead you throw in a couple of asserts just to catch code errors during implementation phase, errors that should be debugged and fixed before release.

"Normal" error issues, i.e. errors due to user actions like opening a file that contains invalid data, input of characters where numbers are expected an so on shall of course be handles the normal way.

Hope I made some sense.

[logan]

Yes, I understand that it can help avoid the extra code in the release build. All you said makes sense.

So, does the author mean to say that whenever your application asserts then it's a bug and you should check that invalid values are not passed again? Had we not used asserts these bugs would have gone unnoticed, but won't have crashed the application as we overload our code with checks for them. Is this what he means to say?

[S_M_A]

Yes both invalid parameters but asserts can also be used say in the middle of a calculation to check your own thinking. Say that you think like "this intermediate result will never be outside -1023 <= x <= 1023 so next step in my calculation can't overflow". A couple of asserts here can save you a lot of trouble don't you think?

So what Steve tries to say is that if no asserts are used at all, some errors will not be spotted at all since they might not be critical. Instead they will propagate into the rest of the system and maybe in version 11.0 suddenly cause a critical error. To track down the root cause at this point may be very hard, it might even be impossible.

Also, by using assert we don't have to spend time in writing and debugging code that actually can make things even worse later on. Code that shouldn't been there in the first place.

[S_M_A]

Thanks for the vote logan.
Although I feel that you probably don't need this post, there are other readers as well...

Asserts help by revealing bugs instead of hiding them but do not by any means reduce the need for a thorough verification of the software. Also, they are removed when building for release so to be able to solve a crash at customer site, other debug supporting mechanisms have to be used as well.

Btw: MS define a VERIFY that act like an assert but is active both in debug & release.

[logan]

Thanks a lot for the replies . Things are clearer now.