The benefits of persistent programming

Question

What is the point of inserting statements into our code? What are the benefits of assertive programming?

private void WriteMessage(string message) { Debug.Assert(message != null, "message is null"); File.WriteAllText(FILE_PATH, message); } 

For example, we can check the message variable and throw an exception here. Why am I using assert here? Or is this the wrong example to see the benefits of statements?

Answer 1

They also support the failing philosophy explained in this article by Jim Shore.

Answer 2

Where some people write:

 /* * This can never happen */ 

It is much more convenient to write it:

 assert(i != -1); 

I like to use statements because they are easy to disable with a simple compile-time constant or do something else, such as preparing an error report. Usually I do not leave a statement (at least not in the usual way) when releasing something.

Using them saved me from making very stupid mistakes on other people's computers. These brave souls who like to test my alpha code. Using them plus tools like valgrind helps ensure that I catch something terrible before committing it.

Answer 3

An important distinction to keep in mind is which errors you would like to catch with the statements. I often use assertions to catch programming errors (i.e., call a method with a zero parameter) and another mechanism for handling verification errors (for example, passing a social security number of the wrong length). For a programming error caught with a statement, I want to fail quickly. For a validation error, I want to react less decisively, because it may be normal for errors in the data (for example, the user makes some kind of data input). In such cases, proper processing may consist in reporting the error to the user and continuing with the operation.

Answer 4

If there is a prerequisite for the method to accept an optional message parameter, then you want the program to be FAIL as soon as the precondition is not fulfilled, and the source of the error must be fixed.

I believe that claims are more important when developing critical software. And, of course, you would prefer to use assertions if the software was formally defined.

Answer 5

For a great discussion of statements (and many other topics related to code building), check out Code Complete by Steve McConnel. He devotes an entire chapter to the effective use of statements.

Answer 6

I use them to verify that I have been provided with a valid dependent class. for exmaple in the DI constructor, you usually take some kind of external class that you depend on to provide some kind of action or service.

so you can argue (classRef! - null, "classRef cannot be null"); instead of waiting for you to pass the classRef message and get some other exception, such as an exception: an access violation or something as ambiguous that might not immediately obvioius from viewing the code.

Answer 7

It is very useful to check our assumptions. Statements constantly check whether the invariant is true. In short, it is used for the following purposes:

• This allows you to implement a fault tolerant system.
• It reduces the spread of errors due to side effects.
• It prohibits (a kind of health check) the system to enter an inconsistent state due to user data or subsequent code changes.

Sometimes I prefer to use assert_return () when we don't want to use try / catch / throw.

 private void WriteMessage(string message) { assert_return(message != null, "message is null"); // return when false File.WriteAllText(FILE_PATH, message); } 

I suggest assert_return () to stop the application by reporting an error in the test build. And then in the production system, it must register and register and return from the function, saying that it cannot do this.