Assert
-
How can it be an exception (to the rule) if it's an invalid state. Assert = never, Exception = in exceptional circumstances. OT: The server gives an 500 error everytime I try to submit the 1st reply. Going back and resumitting works though. :~
**
xacc.ide-0.2.0.57 - now with C# 2.0 parser and seamless VS2005 solution support!
**
Assertions can validly be configured to generate exceptions. The exception is then an indication of a bug. For example, see Standard C++'s logic_error class. http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/classstd_1_1logic__error.html[^] It is still "exceptional" because bugs should be exceptional!
Kevin
-
Shog9 wrote:
Good post, Rama.
Damnit Shog, I said that first!
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New)Yeah, but you called him "5". 5's cool and all, but i figured Rama should get credit for the post.
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
Yeah, but you called him "5". 5's cool and all, but i figured Rama should get credit for the post.
---- Scripts i’ve known... CPhog 1.8.2 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
Shog9 wrote:
Yeah, but you called him "5". 5's cool and all, but i figured Rama should get credit for the post.
Blast!!!
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New) -
>> In a release build, since the Assert gets ignored, the exception acts as a backup error-check perhaps? This is what I don't understand, if a condition must be met or else the program will fail, then why use Assert instead of throwing exceptions? Generally, error checking should be included in both debug and release build. When you assert something, you know there is a possibility that the condition might fail, but then if you assert the condition, it is only checked in debug build, which implies that such checking should be ignored in release build. But if such check can be ignored in release build, why checking it in a debug build then?
VAIO Blue wrote:
if a condition must be met or else the program will fail, then why use Assert instead of throwing exceptions?
An assertion represents a violation of a method's contract or is indicative of a logic error. By using an assertion we convey our intent. We can then distinguish between what is a logic error and what is a more general exception.
VAIO Blue wrote:
Generally, error checking should be included in both debug and release build.
Correct.
VAIO Blue wrote:
When you assert something, you know there is a possibility that the condition might fail, but then if you assert the condition, it is only checked in debug build, which implies that such checking should be ignored in release build.
We often set up things this way but it need not be so. Try looking up the theory of Design by Contract. The reason we often set up things this way is that we aim to have fully debugged the software during testing, in which case the assertions are valuable. When we ae confident we then remove them during release to improve performance (but leave in error handling that is not to do with logic violations, i.e., external or user errors). But in real applications there can be a degree of selectivity in how we do this.
VAIO Blue wrote:
But if such check can be ignored in release build, why checking it in a debug build then?
Because they help us to debug the application as we're developing it. They also aid the maintenance programmer in producing only valid consumptions of existing code.
Kevin
-
VAIO Blue wrote:
What is the point of using assert in this case?
Stupid code, the Assert checks an invalid condition, yet the 'invalid' condition is handled. Find the author, ask him to find his mistake, if he does not, shoot him.
**
xacc.ide-0.2.0.57 - now with C# 2.0 parser and seamless VS2005 solution support!
**
Quite to the contrary, this is extremely good practice. An assert will rarely fire. In debug builds, you want to know when they happen and resolve the issue. In the rare chance they happen in production code, you want some sort of graceful recovery rather than a fault.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
I often see code like this. void foo(int i = -1) { Assert(i != -1); if(i == -1) throw; .... work with i ... } What is the point of using assert in this case?
-1 is a default value. This code is dumb. It means two things 1 - it allows the compiler to accept calls to foo with no parameter ( the default is then set ), and 2 - it asserts when that method is called. If they just did void foo (int i ) then calls to foo with no arguments simply would not compile.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
This is for making the code robust. It is an extreely good practice for large scale software development. If you look at ATL and also MFC source code this pattern is used everywhere. You will also find code like this in rotor and as far as I think in the .Net framework BCL also. Steve McConnell author of Code Complete suggests the use of both assert and error handling (exceptions in this case). He cites the example of Microsoft Word.
In the source code for Microsoft Word, for example, conditions that should always be true are asserted, but such errors are also handled by error-handling code in case the assertion fails. For extremely, large complex applications like Word, assertions are valuable because they help to flush out as many development-time errors as possible. But the application is so complex (millions of lines of code) and has gone so many generations of modification that it isn't realistic that every conceivable error will be detected and corrected before the software ships, and so errors must be handled in the production version of the system as well.
The other advantage of Assert is that you can directly stop in the debugger. Assert -> Figure problems in design time. Exception -> Handle any errors that may have been missed. In this case if i is -1 it can cause problems in the code. So you have to throw an exception.
Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -Brian Kernighan
Yeah, I have to admit, in seeing that the compiler was allowing a call with no parameters, only to assert it ( which is dumb ), I overlooked the obvious, that an assert is still a good idea ( although I can't imagine why -1 would be the ONLY possible int value that would be unacceptable ).
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
Good post - 5 :-)
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New)Anyone who quotes code complete deserves a 5, but the code is still dumb. Why have -1 as a default parameter, if it will only ASSERT ? In what situation could -1 be the only int that needs to ASSERT, -2 is fine and so is -234232 ?
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
It depends on what exceptions are thrown. You could have code higher up the call stack that handles the explicitely thrown exception type gracefully, and have the exception generated by the Assert statement left to propogate to the top. That way while debugging you're assured of seeing each and every Assert, but in release mode the code will continue to run fine. Then you get into the whole "exceptions vs return values" argument.
cheers, Chris Maunder
CodeProject.com : C++ MVP
FIX: A MFC program created in Visual Studio .NET 2003 unexpectedly quits when you try to close it[^]
But return values are heaps better - you can ignore those !!!!
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
But return values are heaps better - you can ignore those !!!!
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
:doh: Where's the "la la la I can't hear you" emoticon when you need it.
cheers, Chris Maunder
CodeProject.com : C++ MVP
FIX: A MFC program created in Visual Studio .NET 2003 unexpectedly quits when you try to close it[^]
-
Shog9 wrote:
Good post, Rama.
Damnit Shog, I said that first!
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New)You're "me too"-ing a "me too" post? :sigh:
cheers, Chris Maunder
CodeProject.com : C++ MVP
FIX: A MFC program created in Visual Studio .NET 2003 unexpectedly quits when you try to close it[^]
-
Anyone who quotes code complete deserves a 5, but the code is still dumb. Why have -1 as a default parameter, if it will only ASSERT ? In what situation could -1 be the only int that needs to ASSERT, -2 is fine and so is -234232 ?
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
Christian Graus wrote:
Why have -1 as a default parameter, if it will only ASSERT ? In what situation could -1 be the only int that needs to ASSERT, -2 is fine and so is -234232 ?
From an earlier post I made :- [snip] I think, what happened is this. There was this method that didn't take any args. Later, an overload was added that took an arg. Now they wanted to trace out all calls to the method that used the arg-less version. So they set the default value to -1, and assert on -1. The coder (who was probably inexperienced) may not have been sure if that was good enough, and meaninglessly added an exception block too. That's my inference on what may have happened. [/snip]
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New) -
Christian Graus wrote:
Why have -1 as a default parameter, if it will only ASSERT ? In what situation could -1 be the only int that needs to ASSERT, -2 is fine and so is -234232 ?
From an earlier post I made :- [snip] I think, what happened is this. There was this method that didn't take any args. Later, an overload was added that took an arg. Now they wanted to trace out all calls to the method that used the arg-less version. So they set the default value to -1, and assert on -1. The coder (who was probably inexperienced) may not have been sure if that was good enough, and meaninglessly added an exception block too. That's my inference on what may have happened. [/snip]
Regards, Nish
Nish’s thoughts on MFC, C++/CLI and .NET (my blog)
Currently working on C++/CLI in Action for Manning Publications. Also visit the Ultimate Toolbox blog (New)Well, there's an easy way to find all the calls that take the argless version. Block it out as a comment, then hit compile, the compiler will list them all far better than someone running the code and trying to find every execution path that calls it. So, it's still dumb.
Christian Graus - Microsoft MVP - C++ Metal Musings - Rex and my new metal blog
-
:doh: Where's the "la la la I can't hear you" emoticon when you need it.
cheers, Chris Maunder
CodeProject.com : C++ MVP
FIX: A MFC program created in Visual Studio .NET 2003 unexpectedly quits when you try to close it[^]
-
VAIO Blue wrote:
What is the point of using assert in this case?
Stupid code, the Assert checks an invalid condition, yet the 'invalid' condition is handled. Find the author, ask him to find his mistake, if he does not, shoot him.
**
xacc.ide-0.2.0.57 - now with C# 2.0 parser and seamless VS2005 solution support!
**
ASSERT only works in debug builds, and are generally intended to catch stupid programmer tricks during the initial development cycle. The exception handling is there for release builds for a more graceful error handling. I generally only use ASSERT for null pointer checks, and then follow the ASSERT with error handling code "just in case"...
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
I often see code like this. void foo(int i = -1) { Assert(i != -1); if(i == -1) throw; .... work with i ... } What is the point of using assert in this case?
Especially since Nunit uses the very same assert in a different manner, ie test cases. I spell out my System.Diagnostics.Assert for that very reason.
On two occasions I have been asked [by members of Parliament], 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question. - Charles Babbage