Assert (false) in language D

Question

TDPL describes the behavior of the assert(false); . Such a statement is not removed from the release build (like all other statements) and, in fact, immediately stops the program. The question is why? Why such confusing behavior? They can add halt(); or something like that to stop the program.

Sometimes I use the following construct in C ++ code:

 if (something_goes_wrong) { assert(false); return false; } 

Obviously, such a construction is impossible in D.

UPDATE

Be clear. The question is why int x=0; assert(x); int x=0; assert(x); will not crash the version of the program version, but assert(0); will be? Why such a strange solution for language design?

Answer 1

which is older than D, and is usually used to tell the compiler that you do not expect to ever get to this point in the code, because that would mean that something is very bad in the code

typical use looks like this

 MyStruct foo(){ foreach(s;set){ if(someConditionGuaranteedToHoldForAtLeastOne(s)) return s; } //now what I can't return null; assert(0);//tell the compiler I don't expect to ever come here } 

Answer 2

A statement is used to confirm something about the state of your program at a specific point in the program. If the statement is not executed, then there is an error in the program, and there is no point in continuing the program. But there’s something to be done for approval - especially that related to making function calls - so you usually disable them in release mode ( -release for dmd does this automatically). You run your program and check it in debug mode, and I hope you find yourself in any conditions that lead to statement failures so that you can catch and fix these errors. Then you hope that you caught them all and that in release mode, nothing is terribly bad if you did not.

But what about entering codes that should never be reached under any circumstances? This is where assert(0) comes in.

It functions like a normal statement without -release , so you get good stack traces and all this when you click on it, but since it is something that should not only never happen, but lead to completely incorrect code, it remains in release mode but changed to stop instruction. Classical places of their use can be such cases as

 switch(var) { ... //various case statements that should cover all possible values of var ... default: assert(0, format("Invalid value for var: %s", var)); } 

where the default case should never be hit, and if so, the logic in your function is incorrect or

 string func(int i) nothrow { try return format("%s", i); catch(Exception e) assert(0, "Format threw. That should be impossible in this case."); } 

where, as long as the func logic is correct, it should not be possible to throw it, but it is called a function that can be thrown under certain circumstances (and not in them), so you need to use a try-catch block to make the compiler happy. Then you put assert(0) in the catch block so that you can catch it if it really can throw.

The classic case for assert(0) actually used by the compiler itself - and this must be inserted at the end of the function, which does not end with the return statement, so that the code does not try to continue if your code logic is incorrect and you somehow end up at the end of the function.

In all such cases, you are dealing with code that cannot be hit while your code is correct, but it is a safe network if you made a mistake in your logic. The benefits of using assert(0) for this with a bare-stop command are that when -release enabled, you get the correct stack trace and there may be a nice error message with it. Then, when the -release function is -release on, it turns into a halt statement, so you are guaranteed that your program will not get into an invalid state by traversing the line with assert(0) .

You use the usual statements for things that you want to check in debug mode, but not in release mode, and you use assert(0) for the code paths you want to guarantee never get into any mode.

Answer 3

The only reason you can disable assertions in releases is to save time by not experiencing the assert expression when it is likely to just go away.

"false" never passes.