From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id 1384DBC6B for ; Tue, 28 Aug 2007 11:26:48 +0200 (CEST) Received: from mail17.bluewin.ch (mail17.bluewin.ch [195.186.18.64]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l7S9QlEY011950 for ; Tue, 28 Aug 2007 11:26:47 +0200 Received: from [10.0.1.2] (85.2.108.101) by mail17.bluewin.ch (Bluewin 7.3.121) id 46C9BEB9001CCDE9 for caml-list@yquem.inria.fr; Tue, 28 Aug 2007 09:26:45 +0000 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <1188257636.7533.23.camel@localhost.localdomain> References: <9FA25C33-04DD-46BD-8959-873DDD2FFF82@epfl.ch> <1188055755.10796.37.camel@rosella.wigram> <1188257636.7533.23.camel@localhost.localdomain> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Subject: Re: [Caml-list] Has the thread cancellation problem evolved ? Date: Tue, 28 Aug 2007 11:26:47 +0200 To: caml-list@yquem.inria.fr X-Mailer: Apple Mail (2.752.2) X-Miltered: at discorde with ID 46D3EA57.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; bunzli:01 buenzli:01 gerd:01 stolpmann:01 toplevel:01 toplevel:01 computations:01 polymorphic:01 imho:01 stack:01 exception:01 exception:01 caml-list:01 computation:01 computation:01 Le 28 ao=FBt 07 =E0 01:33, Gerd Stolpmann a =E9crit : > Nevertheless, I don't think this is a good thing. Raising an exception > at potentially any moment is a problematic thing. E.g. code like > > let x =3D try Some(List.assoc ... with _) -> None > > where the author implicitly assumes that it is only Not_found that can > happen and the code is just plain wrong if anything else is encoded =20= > into > the exception. But this is sloppy programming anyway. The author is plain wrong in =20 assuming that only Not_found can be raised, he is asking for a =20 potential time consuming debugging session. 1) If x is polymorphic then List.assoc may raise Invalid_argument =20 (because of compare). 2) If the computation of x is embedded in a larger computation the =20 call to List.assoc may raise Stack_overflow. 3) The allocation of the block for Some may raise Out_of_memory. 4) If we are in the toplevel Sys.Break may be raised. IMHO the only place where a catch all handler is allowed is in a =20 toplevel main loop (or a function monitoring other computations). Daniel