Defensive programming - Assertions

[Simon P Stevens]

I try to use assertions to check assumptions that I know must be valid. If there is a chance the assumption is invalid, I'll throw an exception instead. I'll admit though, it does depend on my mood slightly. Sometimes I assert less than my own mental guidelines dictate.

Simon

[Thomas Weller 0]

When it comes to public methods/properties, I use something like

if (this argument is crap)
{
throw new ArgumentException("no crap please!");
}

The same if there are some other data from outside (e.g. reading a file or getting data from a DB). Speaking of non-public members, I heavily rely on unit tests, not on Debug.Assert. The rationale is: If I can protect my code from invalid input, then I can concentrate on the inner workings of my code. The many if(...){ throw ... } statements make the code somewhat harder to read, but in my view they are part of a methods signature, so they should be there anyway. One can use AOP to ease this burden, if appropriate. I think, automated unit tests are far better than Debug.Assert. But they are probably not really comparable, since Debug.Assert is something you do in your code, unit tests are something like an extra program you have to write. Regards Thomas

www.thomas-weller.de Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.

[Robert Surtees]

Assert, aka Exploding Comment

[moon_stick]

I use both assertions and unit tests in my code; the units tests are there to test that the behaviour of the function is correct whereas the assertions are used to ensure that supposedly unreachable situations aren't reached, i.e. a non-zero integer passed into a function etc could indicate a problem in the calling routine etc. One of the developers at a company I used to work for liked the idea of using assertions but had the unfortunate habit of writing code like: #if debug Debug.Assert(LoadData()); #endif which then produced spurious results when the build was changed to 'release'. Because of this, I now tend to routinely remove assertions once I've finished writing a function / library before running my unit tests again.

It definitely isn't definatley

[Simon P Stevens]

Thomas Weller wrote:

if (this argument is crap) { throw new ArgumentException("no crap please!"); }

I have a static 'ArgumentHelper' class in a library assembly that has methods like 'CheckForNull' and 'CheckMinValue', that do the checks and throw the exceptions. It improves the readableness of the checking code at the start of methods

ArgumentHelper.CheckForNull(arguement1);
ArgumentHelper.CheckMinValue(arguement2, 0);

Simon

[R Giskard Reventlov]

I tend to use Design-By-Contract[^]. There are a couple of good articles here, such as this one. I do agree, however, that nothing much beats unit testing: eat your own dog food!

me, me, me

[Simon Capewell]

Ah, a classic gotcha. Reminds me of a interview question where they asked when it was appropriate to use ASSERT as opposed to VERIFY. I used asserts lots in C++, it seemed to be the convention in MFC to assert on NULL hWnds and the like, but in .NET code they've tended to get left out. BTW, are you aware that the Assert method is marked with [Conditional("DEBUG")] so the #if/#endif is unnecessary?

[moon_stick]

Simon Capewell wrote:

BTW, are you aware that the Assert method is marked with [Conditional("DEBUG")] so the #if/#endif is unnecessary?

I was just being explicit about my intentions. Obviously.... ;)

It definitely isn't definatley

[Simon Capewell]

Obviously. Double the conditional compilation, double the defensiveness ;)

[Steve Hansen]

Don't forget a string parameter for the parameter name, that way you'll know which argument was incorrect ;) My helper is a:

Argument.NotNull("parameter", parameter);

[Simon P Stevens]

Funny, I do actually pass the name of the parameter in as a string. I just left it out to simplify the example. This is obviously quite a common pattern. Mine is actually the other way round. Parameter first, then string name. I wrote snippets for the ones I use most commonly, so all I type is "exnull" and hit tab twice and it expands out. That way I only have to type the argument name once and it auto fills both parameters. I found that if I passed the string first I had to type it in full with no intellisense, but if I passed the argument object first I could type it and get intellisense help, and then the string value would be auto filled. (All to save a few extra keystrokes :laugh: )

Simon

[Steve Hansen]

My shortcut is nn and resharper allows to fill out the second argument first so it still shows intellisense, plus its smart enough to use parameters so I have to type almost nothing :p

[Douglas Troy]

Yes, I use them as well as Unit Tests, to help catch bugs/design problems.

[Single Step Debugger]

I’m using it in the IO operations.

The narrow specialist in the broad sense of the word is a complete idiot in the narrow sense of the word. Advertise here – minimum three posts per day are guaranteed.

[Henry Minute]

N a v a n e e t h wrote:

I am just wondering, do you guys use Debug.Assert

I may be being a little thick here but if you are suspicious enough of a section of code to put in a Debug.Assert, shouldn't you be putting it in a try/catch (or equivalent) block anyway? On this basis I have never been convinced of the need. Obviously a lot of you do use it and therefore I must have missed the point. Is there an article that any of you would recommend, which explains in words of one syllable, you know beginner level?

Henry Minute If you open a can of worms, any valid solution *MUST* involve a larger can!

[Miszou]

I used ASSERT and VERIFY all the time in C++, but since moving to C# I find that I hardly use them at all. It's probably due to the better exception handling and debugging abilities that have been added since Studio 6.0.

The StartPage Randomizer | The Windows Cheerleader | Twitter