Assert
-
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?
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!
**
-
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!
**
leppie wrote:
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.
In a release build, since the Assert gets ignored, the exception acts as a backup error-check perhaps?
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) -
leppie wrote:
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.
In a release build, since the Assert gets ignored, the exception acts as a backup error-check perhaps?
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)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!
**
-
leppie wrote:
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.
In a release build, since the Assert gets ignored, the exception acts as a backup error-check perhaps?
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?
-
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!
**
leppie wrote:
How can it be an exception (to the rule) if it's an invalid state. Assert = never, Exception = in exceptional circumstances.
I am not justifying the code, I was merely trying to figure out the coder's line of thinking. 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.
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) -
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?
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[^]
-
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?
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
-
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[^]
Chris Maunder wrote:
Then you get into the whole "exceptions vs return values" argument.
At which point I'd rather start discussing the existential meaning of Santa Claus and the Easter Bunny.
regards, Paul Watson Ireland FeedHenry needs you
eh, stop bugging me about it, give it a couple of days, see what happens.
-
leppie wrote:
How can it be an exception (to the rule) if it's an invalid state. Assert = never, Exception = in exceptional circumstances.
I am not justifying the code, I was merely trying to figure out the coder's line of thinking. 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.
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)Nishant Sivakumar wrote:
The coder (who was probably inexperienced)
In my opinion the coder is quite experienced to write such robust code. Ever looked at source code of MFC/ATL you will find such pattern everywhere. Assert and then Error Handling (in this case using exceptions and in case of MFC/ATL using return values).
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
-
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?
I often do things like this. Firstly, the assert will only fire for debug builds i.e. usually when I'm in my IDE. The program will stop at where the problem was detected, not just keep on going. I use VC6 and I don't think it has a "break on exception" feature like VS.NET but even if it did, I wouldn't want to use it. By the time the exception has been caught, you've lost your stack frame and it's generally too late to know what caused the problem. Secondly, I use my own souped-up assert macro that logs a lot of additional information that won't be available in a catch handler (e.g. local variables).
0 bottles of beer on the wall, 0 bottles of beer, you take 1 down, pass it around, 4294967295 bottles of beer on the wall. Awasu 2.2.3 [^]: A free RSS/Atom feed reader with support for Code Project.
-
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
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) -
Nishant Sivakumar wrote:
The coder (who was probably inexperienced)
In my opinion the coder is quite experienced to write such robust code. Ever looked at source code of MFC/ATL you will find such pattern everywhere. Assert and then Error Handling (in this case using exceptions and in case of MFC/ATL using return values).
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
Rama Krishna Vavilala wrote:
Ever looked at source code of MFC/ATL you will find such pattern everywhere. Assert and then Error Handling (in this case using exceptions and in case of MFC/ATL using return values).
Yep, I've seen that pattern before.
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) -
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
Good post, Rama. :)
---- 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
-
Good post, Rama. :)
---- 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:
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) -
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