🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.software.testing
Article #14

Re: Q: assertions before and after testing

#14
From: Taed Nelson
Date: Wed, 13 Sep 1995 23:44
48 lines
2991 bytes
In article <42o1ns$qdk@itchy.adacel.com.au>, owen@itchy.adacel.com.au (Owen Veenstra) writes:
> 
> I am using assertions to detect simple programming and interface 
> problems (ie valid ranges etc).  Having the program die during 
> execution at this point is therefor acceptable.
> 
> However, in the system it will be intgrated into, it is 
> unacceptable to have the module simply crash the system because 
> an assertion failed.  Therefore, assertions would be removed.

What I do is to not use the system assert at all.  I use:

	/* Logging messages.  These can be seen with Microsoft's DebugWin or WinIce. */
	/* ??? Since macros can't have varargs, LOGF does not have braces around it,
	 * which could cause a problem for nested if-else statements.
	 */
	void LogFormatMessage (char *format, ...);
	#define LOG(string)     { if (IniFileInfo.log) {        \
	                                OutputDebugString ("SM:  " string "\n"); } }
	#define LOGF            if (IniFileInfo.log)  LogFormatMessage
	
	/* Taed's ASSERT code -- with or without a return value. */
	#define NOT_REACHED 0
	#if defined(_DEBUG)
	#define ASSERT(expr)            { if (! (expr)) {       \
	                                        LOGF ("ASSERTION FAILED: \"%s\" at line %u in file \"%s\".",      \
	                                                #expr, __LINE__, __FILE__);     \
	                                        _asm { int 3 }; \
	                                        return (SM_STATUS_ASSERT_FAILURE); } }
	#else
	#define ASSERT(expr)
	#define ASSERT_VOID(expr)
	#endif

As you can see, my ASSERT pops into my debugger (this is DOS/Windows, mind you
  -- on Unix, I just use the standard assert macro), and then returns an
  error.  That way if the debugger is not running, it is OK.  I do get rid of
  the ASSERT code if it is not debugging, but you can easily fix that.

Note the clever printing of a log message if the assertion fails.  That way, I
  cover all the bases -- log file, debugger, and error value.  I work with
  partners who do not have access to my source code, and so all of those come
  in handy -- particularly if they just send me log files.

As far as my opinion on the "should one have asserts in production code", I'm
  of two minds.  As you can see, on my current project, I left them out.  On
  other projects, I've left them in.  I guess it depends on my level of
  confidence.
Technical Details
Message-ID: <DEvBAF.5BC@berlioz.nsc.com>
Path: arc1-ca.pugleaf.net!in1.uu.net!pipeline!psinntp!psinntp!psinntp!voder!berlioz!desktop!nelson
References: <42o1ns$qdk@itchy.adacel.com.au>

Show Full Headers
Complete Article Headers
Newsgroups: comp.software.testing,comp.lang.c
Path: arc1-ca.pugleaf.net!in1.uu.net!pipeline!psinntp!psinntp!psinntp!voder!berlioz!desktop!nelson
From: nelson@desktop.nsc.com (Taed Nelson)
Subject: Re: Q: assertions before and after testing
X-Nntp-Posting-Host: desktop
Message-ID: <DEvBAF.5BC@berlioz.nsc.com>
Keywords: assert test
Sender: news@berlioz.nsc.com (UseNet News account)
Organization: Interactive Multimedia, National Semiconductor (Santa Clara CA USA)
References:  <42o1ns$qdk@itchy.adacel.com.au>
Date: Wed, 13 Sep 1995 23:44:39 GMT