Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!microsoft!alonzo
From: alonzo@microsoft.UUCP (Alonzo Gariepy)
Newsgroups: comp.lang.eiffel
Subject: Re: Assertions (was: Re: Eiffel vs. C++)
Keywords: Assertions
Message-ID: <6045@microsoft.UUCP>
Date: 16 Jun 89 01:42:03 GMT
References: <807@batserver.cs.uq.oz> <136@ssp1.idca.tds.philips.nl> <10368@socslgw.csl.sony.JUNET>
Reply-To: alonzo@microsoft.UUCP (Alonzo Gariepy)
Organization: Microsoft Corp., Redmond WA
Lines: 37

In article <10368@socslgw.csl.sony.JUNET> diamond@csl.sony.junet 
>
>Hmm.  I guess the real world needs assertions that print out WARNING
>messages and then continue executing with incorrect results.  And
>maybe even the warnings should be directed to /dev/null unless the
>execution-time invoker matches the the compile-time developer.
>(I wish this were rhetorical....)
>--
>Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net)

The real world has assertions that do exactly that and there is
no reason to wish your comment was rhetorical.  Ignorable assertions
are a major convenience in debugging and testing and make for robust
system code.

It is frustrating to have a debugging session stopped dead by an 
assertion, and it is often convenient to redirect warning messages 
to /dev/null so that they don't mess up the debug output you are
interested in.

In released code (especially system software) assertions can check for 
and report illegal parameters, but continue execution with reasonable 
defaults so that programs are still functional.  Once such an error
is reported, it might be nice to redirect such messages to /dev/null
until such time as the problem is fixed.

Such assertions are also handy when it is found that illegal 
parameters have been slipping through and taking advantage of 
undocumented side-effects.  Future versions of a library can 
assert the legality of parameters without breaking existing 
programs.

Ideally, we would all like a programming language that will tell us
when we are not being precise, but which can figure out what we
really meant and tell us before going off to do it.  For maintenance
reasons it should also modify the code to be more precise once we
have accepted its interpretation.