When should I use assert?

—————————————————-Michael to Pongba

There are 2 ways to do this:

Method One: Section *pimagesection = new section (pimage);

ASSERT (Pimagesection);

Method Two: Slightly

PS: Now the project group code with the first method, and also do not write the log, each time the client down, positioning problems are long, people are very crash. And it's all over the assert.

I personally think that with the assert place, is a more serious error, and even can not let the program run again.

If it is too cruel to use asset everywhere, sometimes you should gently skip, and then write the log, return. Tell me where the run failed.

—————————————————-

Here is my answer to this question:

First of all, we need to point out a very important, the discussion must be clear before the issue, the assert should not be used directly, but should be packaged, such as Microsoft has an Assert macro, you can track the line file of the useful information, in addition, you can cancel the assert by conditional compilation. For a long time, it can only be said that this kind of programming common sense has not been set up.

Although the original text is very simple, actually involves a few aspects, one is version management release, one is the error handling mechanism, one is how to write the log, we discuss each.

What is the first case with assert, and under what circumstances should the wrong case be handled?

A mature code inside, probably have Chand code is to check the wrong, fault tolerance. For example, if you write an API or use external functions, others want to call, you want to make sure that the incoming pointer is not empty, the passed arguments are valid, this should not be, note that the assert should not be used, because these conditions out of your control.

What can be used to assert, should be those that rarely occur, and you can control those code passages, such as object* p = new Object, return null pointer, in this case most of the memory request error, even if you fault-tolerant, the subsequent logic will not be normal, You should stop running the error at this time. There is your internal function (note is the inside of your program OH), because the internal function of the code responsibility is actually your own, you pass the wrong argument can only say that the level is too bad to blame others. One might say, what if another programmer in the same group calls this function? This kind of situation certainly will have, actually also cannot avoid, but can use assert and code review these means to standardize, the problem inside the same program group belongs to internal contradiction good solves much.

So, the big principle can be this: the internal function as far as possible to simplify the fault-tolerant mechanism, a little more harsh, while the external interface is as tolerant as possible, error processing should be gentle.

The second question is, how do you write an assert?

I have already mentioned, do not use assert directly, preferably wrapped, add #ifdef _DEBUG This conditional compilation option, ensure release version does not eject assert. There are also versioning issues involved, and a commercial product release typically contains two versions (release version and debug checked version), even for Windows operating systems. In release version to Disasble assert, this time if the error can be used after the crash dump mechanism to catch the trace, and to explain the release version to accompany the PDB file (or Linux similar files), to ensure that crash dump can be located. The debug version is also sent to the user, which allows the user to return more detailed information. Each build out of release, debug should be properly backed up, in the future customers submit bugs, the corresponding version and the PDB, you can accurately locate, there will be no difficult error phenomenon.

Alternatively, you can add the log logs option. Run a problem here, logging is also a big problem, to consider multithreading and performance issues, in fact, not to join the log system is all right, say a nasty, for those 2B number one person, any good things can be used to rotten. General assert run out, for the customer is equivalent to crash, so you can refer to Google's crash report open source projects, such as Windows can use crash dump mechanism to catch crashes when the call stack, so even if fail Soon fail Fast is not very hard to read. These are common sense things, and a normal software development company should accumulate this code of wealth.

Original address: http://www.cnblogs.com/lua5/archive/2010/12/05/1896756.html

When should I use assert?