views:

334

answers:

6

What is the point of putting asserts 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 do I use assert here ? Or is this a wrong example to see benefits of asserts ?

+1  A: 

If there is a specified pre-condition for the method to take a non-null message parameter, then you want the program to FAIL as soon as the pre-condition doesn't hold and the source of the bug must then be fixed.

I believe assertions are more important when developing safety-critical software. And certainly you would rather use assertions when the software has been formally specified.

Peter Perháč
I commented this up because it follows the design principles from the book "Design by contract". Where you specify your functions pre and post condition. Though post condition normaly tends to be more complex that pre condition depending on the context.Just for a mini answer. Asserts are useful at catching developer or miss communication between teams on how modules such operate. Also there should be a separation between the core framework of the engine and also the user input area to mix to two together is folly.
Chad
+7  A: 

They also support the philosophy of fail fast, explained in this article by Jim Shore.

Shane Fulmer
wonderful, thanks !
Canavar
+1  A: 

For an excellent discussion of assertions (and many other topics related to code construction), check out Code Complete by Steve McConnel. He devotes an entire chapter to effective use of assertions.

JayMcClellan
A: 

I use them to verify that I have been supplied valid dependent class. for exmaple in constructor DI, you usually are accepting some sort of external class that you are dependent on to provide some action or service.

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

MikeJ
+1  A: 

An important distinction to consider is what sorts of errors you would like to catch with assertions. I often use assertions to catch programming errors (i.e., calling a method with a null parameter) and a different mechanism to handle validation errors (e.g., passing in a social security number of the wrong length). For the programming error caught with the assertion, I want to fail fast. For the validation error, I want to respond less drastically because it may be normal for there to be errors in the data (e.g. a user doing data entry of some sort). In those cases the proper handling might be to report the error back to the user and continue functioning.

Rob Scott
+5  A: 

Where some people would write:

/*
 * This can never happen
 */

Its much more practical to write:

assert(i != -1);

I like using asserts because they are easily turned off with a simple compile time constant, or made to do something else like prepare an error report. I don't usually leave assertions turned on (at least, not in the usual way) when releasing something.

Using them has saved me from making very stupid mistakes on other people's computers .. those brave souls who enjoy testing my alpha code. Using them plus tools like valgrind helps to guarantee that I catch something awful before committing it.

Tim Post