[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: assert vs. abort
From: |
John Darrington |
Subject: |
Re: assert vs. abort |
Date: |
Tue, 4 Apr 2006 08:42:26 +0800 |
User-agent: |
Mutt/1.5.9i |
On Mon, Apr 03, 2006 at 08:03:22AM -0700, Ben Pfaff wrote:
John Darrington <address@hidden> writes:
> On Sat, Apr 01, 2006 at 11:16:42AM -0800, Ben Pfaff wrote:
>
> > How about this:
> >
> > ASSERT() -- for cheap, important checks
> > ASSERT1() -- for more expensive or less important checks
> > ASSERT2() -- for expensive checks
> > ASSERT_LEVEL -- if defined to a number, checks at the
given
> > level or higher are disabled.
> > NOT_REACHED() -- as discussed
> Doesn't this still leave a problem if we want to add a level between 1
> & 2 ?
I am confused why we would want to do that. I wouldn't think
we'd want more than a couple of levels.
However--I haven't had much experience with multiple levels of
assertions. Have you? If you do, then perhaps your experience
can guide our choices.
Well I've worked on systems which have multiple levels of debug and/or
logging which is kind of similar. Most of these have started out with
far too many levels, and thus were too unwieldy. So I think that 3
levels is probably good to start with. But, in general, my experience
tells me that whenever I try to predict requirements in advance, I
invariably get it wrong. Thus, I think it would be prudent to design
the system so that we can insert extra levels if it proves to be
necessary.
> I would perform the following sedscript on the above.
> s/ASSERT1/ASSERT_EXPENSIVE/ s/ASSERT2/ASSERT_VERY_EXPENSIVE/
> s/\ 1/\ 10/ s/\ 2/\ 20/
My main objection is that something like ASSERT_VERY_EXPENSIVE is
too long. Is there a shorter way to express the same intent?
Well yes. I chose those names for purposes of the current discussion.
Something more concise would be better. Maybe ASSERT, ASSERT_SURE,
ASSERT_CERTAIN ?
> > * NOT_REACHED should *always* be enabled.
>
> ...though I'd argue that it should just expand to abort() when
> all assertions are otherwise disabled.
>
> I'd have to respectfully disagree. Our "You have discovered a
> bug...." message has brought a number of bug reports which I believe
> would otherwise have gone unreported. Many people won't take the
> effort to report a bug if the program just terminates with the rather
> concise message "Aborted".
You may be right.
However, I only meant to suggest that NOT_REACHED() should just
expand to abort() when *all* assertions were disabled, i.e. at
ASSERT_LEVEL 0.
So long as the default ASSERT_LEVEL (ie what happens when built from a
released tarball) is not 0, then I haven't got a problem with that.
J'
--
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://pgp.mit.edu or any PGP keyserver for public key.
signature.asc
Description: Digital signature