How to use Assert micros in c++ error handling ?

[yusufjammy]

What is the purpose and how to use user defined Assert micros in c++ error handling ??

[alexis4]

http://msdn.microsoft.com/en-us/library/ezb1wyez%28VS.71%29.aspx

[weaknessforcats]

You should not be using asserts in C++. Asserts are from C and are there due to weaknesses in the C language.

An assert becomes a null when the code is compiled for release. Then when the "assert" fails, the production program crashes on your user. Unless, of course, you hand your user a debug version and it crashes dispaying the assert message. Both of these cases are not acceptable.

In C++ you shoule be using try/catch blocks instead of asserts.

[Banfa]

It's a little more complex than using try/catch blocks instead of asserts. A try/catch block relies on the called code producing an exception where as a assert tests some boolean expression, they are fundamentally different mechanisms.

You would probably have to change the code in places to return errors to throw exceptions as well as using try/catch blocks.

[weaknessforcats]

Yes, that's correct.

Do not use the assert in C++.

[yusufjammy]

Thanks but please give some example

[whodgson]

As weaknessforcats would be fully aware (and from my limited reading) the C++ ISO lists the C++ header <cassert> which defines the assert macro. The few references i have read recommend the liberal application of this macro in the boolean context mention by Banfa above primarily to enforce required preconditions during the program development and testing phases. It is understood that it is the OS which reacts to assert when a false condition is triggered.
Why is it undesirable to use the assert macro in this way if the recommended C++ exception handling measures are properly incorporated?

[Banfa]

Personally I have yet to see a project (actually that isn't true I have seen 1 in 20 years) where the programmers and managers where willing to to use different code builds for debug and release.

The problem is that in the case of undefined behaviour, such as writing outside array bounds, altering the code can have a huge effect on the actual symptoms of the bug. So in my experience anything that could be asserted is generally just tested with normal code.

I do not believe it is particularly undesirable from a code point of view but from a managing the project and managing bug reports it has never been desirable because you want your debug code doing exactly the same as the release code.

The one place I did see it used was in the software for a 3G modem where they were trying to squeeze every ounce of power out of the processor for transmission bandwidth so removing all those tests was seen as desirable.