what is an Assertion Error? 2

[nimaata]

i have a program that gives no Assertion Error when compiled and executed as a release, but when i do the same steps in Debug mode (not Relase) and the program opens, i get a "Debug Assertion Failed!", what exactly is an Assertion Error?

i dont know if this is important, but when i click on Retry (from the Abort Retry Ignore option), the dlgdata.cpp is opened and the

"void AFXAPI DDX_Radio(CDataExchange* pDX, int nIDC, int& value)" is pointed to as the issue, also i get the following lines below alot in output

"Warning: skipping non-radio button in group.

 

[Salem]

Assertions are run-time checks at the start of most functions, designed to trap all the illegal parameters which you might pass to a function.

The precise wording of the assert should tell you which parameter is wrong.
Eg.

assert(pDX!=NULL);

would trap the case if you passed a NULL pointer to the function in question. If this is the case, look at how you are calling the function, and fix the code appropriately.

These run-time checks only happen in debug builds, not in release builds. This doesn't mean your error has gone away, it just means the function just took what you passed and decided to try and use it anyway (with varying degrees of success).

> "Warning: skipping non-radio button in group."
Probably what it means - you have a mixture of button types in something, and some of them are not radio buttons.

--

 

[PerFnurt]

>These run-time checks only happen in debug builds, not in release builds.

Depends on your settings. Sometimes you want to react on errors in release builds as well.

/Per
[sub]
www.perfnurt.se[/sub]

 

[nimaata]

sweet, thanks yall

is there a way to turn it off in my settings for debug mode so i dont get the Asserstion Error?

 

[Salem]

> so i dont get the Asserstion Error?
Didn't you read what I said?

Your code is broken, the function detected something was wrong and alerted you to the fact that something was wrong.

Fix the problem, don't sweep it under the carpet and pretend it doesn't exist. After all, that is the whole point of a debug mode, to find and remove bugs.

And people wonder why there is so much lousy software about.

--

 

[nimaata]

i read what u said thanks
i found the problem
but i asked if anyone knew how to turn off the option

 

[PerFnurt]

>but i asked if anyone knew how to turn off the option

Simply make a release build. There is no point in doing a debug build if you ain't gonna use its benefits.

Release build - optimized for performance
Debug build - optimized for finding bugs.


/Per
[sub]
www.perfnurt.se[/sub]

 

[nimaata]

cool,thanks!

 

[chipperMDW]

> is there a way to turn it off in my settings for debug
> mode so i dont get the Asserstion Error?

Why would you want to?

Is there a way to keep that annoying smoke from coming out of your hood when your engine is burning? No, because it signifies something you want to know about.

If your program gives assertion errors, it is broken and you need to fix it.

If you did fix it, as you claim, then good. That assertion error shouldn't happen anymore, and you should have no reason to disable assertion errors in debug mode.

If you get more assertion errors, then you know it's still broken and probably unsuitable for release, so you need to fix it more.


As suggested, you can build in non-debug mode to keep assertion errors from happening, but that won't stop your program from crashing mysteriously or giving incorrect results due to its brokenness, which still hasn't been remedied.


The main reason you turn off assertion errors in production code is not for optimization, but to keep end users from seeing messages like "pDX!=NULL" that are intended for the programmer.

The problem with that philosophy is that, by release time, you should have already tested your program enough that assertion errors no longer occur. In other words, your program should not be broken anymore.

If some bug did slip through the cracks in testing, then some user is going to trigger it sometime, and then the program will crash, or even worse, it will appear to work but work incorrectly -- by automatically injecting a patient with ten times the intended dosage of a drug, maybe.

That's why some people never turn off assertion errors, even in production releases. That way, if someone triggers a bug that no one realized was there, the program stops.

Confusing the doctor with a cryptic message but alerting him to a problem is a better course of action than lulling him into a false sense of security while his patient dies.


Also, leaving the assertion errors in lets your users complain about your program not working. And you should welcome that. When they do, you just got free testing. In fact, if you sold the software, you got someone to pay you to test it.


If you indeed fixed the error, then you have no reason to wory about turning off the feature.

If you didn't, then you should, because your program is broken.


So I ask again: Why would you want to turn off this feature?

 

[PerFnurt]

Well said. Have a star.

/Per
[sub]
www.perfnurt.se[/sub]