| I'm fairly certain that there is no way that Wei would | abandon asserts anyway, but for the record, I believe | that would be a horrible mistake.
I agree with Michael. An assert is an excellent debugging aide. I cannot speak for gcc, but in VC++ when an assert pops, the debugger breaks at the assert. I suppose an alternative would be to breakpoint all the throws. Jeff > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Michael Hunley > Sent: Friday, November 07, 2003 11:07 AM > To: [EMAIL PROTECTED] > Subject: Re: Question: why so many asserts? > > > [rant] > I'm fairly certain that there is no way that Wei would > abandon asserts > anyway, but for the record, I believe that would be a > horrible mistake. As > mentioned by Christian, they are there to catch programming > errors, not > runtime errors. If you are following reasonable development > processes you > should be doing a ton of testing using the debug build and a > debugger to > stop you when it hits an assert. You won't crash > inexplicably (most of the > time anyway) and you get valuable, immediate information > about what the > program is doing wrong. The key thing that Christian failed > to mention is > that, in general, asserts are *automatically* removed in > release mode; so, > unless you tweak the makefiles to do something different, > they will be > compiled out for you. I have found that turning on asserts, but > overloading how they are handled (via macro replacement), in release > candidate builds so I get a diag output (syslog or stdout or > whatever) on > asserts that were missed because of differences between > release and debug > builds is invaluable. Most medium to large apps have lots of > code that > changes between release and debug, even if not intentionally, > that you may > trip an improper coding case only in release. Of course the asserts > themselves are one such change, so it isn't perfect, but I > have caught > optimizer bugs this way and logic errors in seldom tested > code paths (yes, > use code coverage). > [/rant] > > Asserts and exceptions serve incredibly valuable and very distinct > purposes. Use the correct one for your purpose. There are > lots of good > reference material out there in books or on the net. Search > for "coding by > contract" and similar. > > michael > > At 02:15 PM 11/7/2003 +0100, you wrote: > >Quoting Stephen torri ([EMAIL PROTECTED]): > >| I believe that asserts should be eliminated. They only cause the > >| program to 'Abort' and not give you any reason for why. > > > >As other people have replied, ASSERTs in Crypto++ catches > programming > >errors, indicating you've used the library incorrectly. > > > >Such mistakes shold be caught during testing before releasing your > >code. Ideally, your code should be so well-tested that it > would never > >abort in any given (practical) runtime-situation. If you've > done this, > >and especially for embedded devices, you could possibly even remove > >ASSERTs in the release version. > > > >| As a professor I know at Vanderbilt says where is stdout > on a missle? > > > >A good point that code should be properly tested. Apropos, > many UNIX > >daemons close their stdout and stderr filehandles, since > they should be > >performing their tasks silently and invisibly, or at least > give reports > >using alternative channels (such as e.g. syslog). > > > >-- > >Christian Stigen Larsen -- http://csl.sublevel3.org -- mob: > +47 98 22 > >02 15 >
