Defensive programming - Assertions
-
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 manyif(...){ 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 thanDebug.Assert. But they are probably not really comparable, sinceDebug.Assertis something you do in your code, unit tests are something like an extra program you have to write. Regards Thomaswww.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.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
-
I am just wondering, do you guys use
Debug.Assertor some kind of assertions when developing in .NET? I have not seen any .NET projects using it so far. Many articles/books saying it as a good practice and part of defensive programming. I think, the code will be mixed with all these assertions and will become less readable. I prefer to keep the assertions separate from the original code (something like unit test cases). Any thoughts?Navaneeth How to use google | Ask smart questions
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!
-
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()); #endifwhich 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
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?
-
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?
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 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
Obviously. Double the conditional compilation, double the defensiveness ;)
-
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
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);
-
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);
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
-
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
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
-
I am just wondering, do you guys use
Debug.Assertor some kind of assertions when developing in .NET? I have not seen any .NET projects using it so far. Many articles/books saying it as a good practice and part of defensive programming. I think, the code will be mixed with all these assertions and will become less readable. I prefer to keep the assertions separate from the original code (something like unit test cases). Any thoughts?Navaneeth How to use google | Ask smart questions
Yes, I use them as well as Unit Tests, to help catch bugs/design problems.
-
I am just wondering, do you guys use
Debug.Assertor some kind of assertions when developing in .NET? I have not seen any .NET projects using it so far. Many articles/books saying it as a good practice and part of defensive programming. I think, the code will be mixed with all these assertions and will become less readable. I prefer to keep the assertions separate from the original code (something like unit test cases). Any thoughts?Navaneeth How to use google | Ask smart questions
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.
-
I am just wondering, do you guys use
Debug.Assertor some kind of assertions when developing in .NET? I have not seen any .NET projects using it so far. Many articles/books saying it as a good practice and part of defensive programming. I think, the code will be mixed with all these assertions and will become less readable. I prefer to keep the assertions separate from the original code (something like unit test cases). Any thoughts?Navaneeth How to use google | Ask smart questions
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!
-
I am just wondering, do you guys use
Debug.Assertor some kind of assertions when developing in .NET? I have not seen any .NET projects using it so far. Many articles/books saying it as a good practice and part of defensive programming. I think, the code will be mixed with all these assertions and will become less readable. I prefer to keep the assertions separate from the original code (something like unit test cases). Any thoughts?Navaneeth How to use google | Ask smart questions
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