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 KAA29662; Sun, 24 Feb 2002 10:08:25 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA29574 for ; Sun, 24 Feb 2002 10:08:24 +0100 (MET) Received: from mailf.telia.com (mailf.telia.com [194.22.194.25]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g1O98Nv23302; Sun, 24 Feb 2002 10:08:23 +0100 (MET) Received: from gateway (h175n2fls34o849.telia.com [217.208.235.175]) by mailf.telia.com (8.11.6/8.11.6) with ESMTP id g1O98Mh01987; Sun, 24 Feb 2002 10:08:22 +0100 (CET) From: "Mattias Waldau" To: "'james woodyatt'" , "'Xavier Leroy'" Cc: "'The Trade'" Subject: RE: [Caml-list] assert false and -noassert Date: Sun, 24 Feb 2002 10:08:21 +0100 Message-ID: <000001c1bd12$ceaab700$0700a8c0@gateway> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk I totally support the current implementation, you NEVER want a program to just terminate. At least you should be able to say something like "Internal Error" and log it, and then terminate. /mattias P.s. I have observed that users really hate internal error=20 messages, so nowadays I just log the error, and then try to=20 restart the application. In this way the users will not even detect that the application failed. In most cases, they will not report this as an error, they will just tell you when you ask, that the application behaved strange, and that they found a workaround. There exists probably some kind of psychological explanation for their behaviour. For example that people are used to=20 that other people sometimes behave strange, like lying,=20 and they tolerate that. However, people would find it=20 very strange if instead of answering, you just run away. > -----Original Message----- > From: owner-caml-list@pauillac.inria.fr=20 > [mailto:owner-caml-list@pauillac.inria.fr] On Behalf Of james woodyatt > Sent: Wednesday, February 20, 2002 5:36 PM > To: Xavier Leroy > Cc: The Trade > Subject: Re: [Caml-list] assert false and -noassert >=20 >=20 > 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 > >> that > >> it might be nice if -noassert together with "assert false" were to > >> bypass all exception handling and go right into program=20 > termination. =20 > >> It > >> seems to me that if I've used the -noassert option, I've=20 > 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=20 > appropriate=20 > > to map (conceptually) fatal errors (such as a failed=20 > assertion) to an=20 > > exception? There is one pitfall with this approach, namely that a=20 > > catch-all "try ... with x -> ..." might inadvertently hide=20 > the fatal=20 > > error. On the other hand, the strenght of this approach is that it=20 > > enables your program to clean up and possibly log a detailed error=20 > > message before termination. >=20 > It *is* appropriate to map conceptually fatal errors (such as failed=20 > assertions) to exceptions. I have a library. It contains=20 > assertions. =20 > I want to test it. I have a list of thirty test functions. =20 > I iterate=20 > the list to apply all the functions to test the library,=20 > wrapping each=20 > one in a "try ... with x -> ..." clause. Result: all thirty=20 > functions=20 > are applied, and I know how many of them raise the Assert_failure=20 > exception. >=20 > 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. >=20 > That's why, when the -noassert flag is used, I would prefer=20 > that "assert=20 > false" map to an immediate program termination, =E1 la=20 > "abort()" in the C=20 > language. In fact, if that's what ocamlopt inserted in this=20 > case, i.e.=20 > a call to abort() in the C library, I would find that optimal. >=20 >=20 > -- > j h woodyatt > "...the antidote to misinformation is more information, not less." > --vinton cerf >=20 > ------------------- > To unsubscribe, mail caml-list-request@inria.fr Archives:=20 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 ------------------- 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