From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id RAA11859; Wed, 20 Feb 2002 17:35:39 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA13002 for ; Wed, 20 Feb 2002 17:35:39 +0100 (MET) Received: from wetware.wetware.com (wetware.wetware.com [199.108.16.1]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g1KGZbH21837; Wed, 20 Feb 2002 17:35:37 +0100 (MET) Received: from kallisti.apple.com(wetware.wetware.com[199.108.16.1]) (2800 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Wed, 20 Feb 2002 08:35:35 -0800 (PST) (Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jan-4) Date: Wed, 20 Feb 2002 08:35:50 -0800 Subject: Re: [Caml-list] assert false and -noassert Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: The Trade To: Xavier Leroy From: james woodyatt In-Reply-To: <20020218150007.A20887@pauillac.inria.fr> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.480) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Monday, February 18, 2002, at 06:00 , Xavier Leroy wrote: > [I wrote:] >> While we are on the subject of the assert function, it occurs to me=20= >> that >> it might be nice if -noassert together with "assert false" were to >> bypass all exception handling and go right into program termination. =20= >> It >> seems to me that if I've used the -noassert option, I've made a = promise >> that the code compiled with it will never raise the Assert_failure >> exception. > > This is a topic that we've discussed at some point: is it appropriate > to map (conceptually) fatal errors (such as a failed assertion) to an > exception? There is one pitfall with this approach, namely that a > catch-all "try ... with x -> ..." might inadvertently hide the fatal > error. On the other hand, the strenght of this approach is that it > enables your program to clean up and possibly log a detailed error > message before termination. It *is* appropriate to map conceptually fatal errors (such as failed=20 assertions) to exceptions. I have a library. It contains assertions. =20= I want to test it. I have a list of thirty test functions. I iterate=20= the list to apply all the functions to test the library, wrapping each=20= one in a "try ... with x -> ..." clause. Result: all thirty functions=20= are applied, and I know how many of them raise the Assert_failure=20 exception. At some point, I want to turn off the assertions. My expectation is=20 that -noassert would then compile the library so that it never raises=20 the Assert_failure exception. Unfortunately, the "assert false" case=20 is... well, an exception to the general rule. That's why, when the -noassert flag is used, I would prefer that "assert=20= false" map to an immediate program termination, =E1 la "abort()" in the = C=20 language. In fact, if that's what ocamlopt inserted in this case, i.e.=20= a call to abort() in the C library, I would find that optimal. -- j h woodyatt "...the antidote to misinformation is more information, not less." --vinton cerf ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners