pspp-dev
[Top][All Lists]
Advanced

[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.


Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]