Re: assert vs. std::logic_error?
On Nov 24, 2:30 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:
On Fri, 23 Nov 2007 05:54:40 -0800 (PST), James Kanze wrote:
On Nov 23, 12:07 am, rpbg...@yahoo.com (Roland Pibinger) wrote:
On Wed, 21 Nov 2007 07:54:11 -0800 (PST), werasm wrote:
When I have errors due to requirements change inside my
software boundaries that cause code to break, I assert.
asserts are (manual) code instrumentations in order to find
bugs in your program. asserts are never used in (compiled
into) production code (at least not by people who understand
asserts).
I suppose you wear a lifejacket when in the harbor, and take it
off when you go to sea as well.
The 'assert lifejacket' is filled with lead. It sinks
(crashes) you at the first possible moment; assert never
rescues anyone.
Obviously, you've never worked on a critical system. Or any
robust software. If a program is not working correctly, the
most desirable behavior is almost always that it crash as
rapidly as possible, so that the error is recognized
immediately.
No engineer would remove the asserts from code unless the
profiler said it was necessary.
Name one publicly known C/C++ Unix- or Windows-program that
ships with asserts, client or server (MS-Word, Firefox,
Unix-tools (sed, grep,...), Apache, ... which??).
Name one significant process control system or major server
which doesn't have assert's active. The version of Apache I
manage certainly has its asserts active. As do all of the other
servers running where I work.
As for the other programs you mention: they crash often enough
that something is detecting fatal errors. Maybe if Firefox did
use asserts, I could get more information than just segment
violation. (Off hand, it wouldn't surprise me if there wasn't a
single assert in grep or sed. But the versions I've seen
delivered are compiled without defining NDEBUG.)
The assert facility was, in fact, carefully designed to allow
removing isolated asserts, without removing them globally, so
that you could remove only the ones the profiler said were
necessary, without removing the others.
Nope, assert is controlled by the global compiler define NDEBUG.
I'd suggest that you reread the standard. The insert header is
explicitly specified to not be idempotent; you can include it as
many times as you wish, and each time, it redefines the
assertion behavior according to the current state of NDEBUG.
And I've never seen NDEBUG defined in the invocation line of the
compiler. Only an idiot would do something that stupid. You
define it only when you absolutely need to.
It was carefully designed as a simple but effective tool to
find bugs during the development phase. It wasn't designed for
error reporting in released programs.
The assert facility was also carefully designed so that
asserts would be active by default; you have to take explicit
steps to turn them off.
'assert' is an overloaded term. It seems that you mix assert
as in C/C++, Assert as in DbC, error and exception handling.
In C++ assert is meant and only useful as a bug detection tool
during developement. Released programs may have 'feedback
agents' or other crash reporting mechanisms but that's an
entirely different breed.
It depends. When you deliver shrink wrapped software, you'll
probably want your own, custom assertion facility, in order to
control the error message (and where it goes). When you're
writing software for in house use, of custom software for a
customer, the standard assert is usually largely sufficient.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34