From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id B7A79BBC4 for ; Wed, 1 Feb 2006 18:30:37 +0100 (CET) Received: from mail.barettadeit.com (h213-255-109-130.albacom.net [213.255.109.130] (may be forged)) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k11HUbgH002231 for ; Wed, 1 Feb 2006 18:30:37 +0100 Received: from [10.0.0.10] (alex.barettalocal.com [10.0.0.10]) by mail.barettadeit.com (Postfix) with ESMTP id BEA7D12564; Wed, 1 Feb 2006 18:31:30 +0100 (CET) Message-ID: <43E0EDFC.8010803@barettadeit.com> Date: Wed, 01 Feb 2006 18:21:00 +0100 From: Alessandro Baretta User-Agent: Debian Thunderbird 1.0.7 (X11/20051017) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Cooper Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Private exceptions References: <43DE235C.5050404@barettadeit.com> <20060201163640.GB20172@localhost> In-Reply-To: <20060201163640.GB20172@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 43E0F03D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; baretta:01 baretta:01 barettadeit:01 caml-list:01 re-raise:01 explicitely:01 barettadeit:01 xcaml:01 xcaml:01 asxcaml:01 wrote:01 wrote:01 exception:01 exception:01 exceptions:01 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.3 Eric Cooper wrote: > On Mon, Jan 30, 2006 at 03:31:56PM +0100, Alessandro Baretta wrote: > > But the ability to match any exception (and re-raise it, without > knowing anything more about it) is essential for implementing > constructs like "unwind-protect", "with-open-file", suspend/force, > etc. You are right, I must admit. Yet the problem remains. There are times when catching exceptions is unsafe. In my case, the exception aborts a database transaction. If the exception is not propagated to the calling transaction manager call, this will continue to execute the current transaction outside of the transaction block--as a rollback has already been issued. Now, of course there is never only one way to solve a given programming problem, and I did solve mine without tampering with the exception system too much--except that I no longer export the exception signalling a transaction rollback, so that at least it cannot be *explicitely* filtered. Alex -- ********************************************************************* http://www.barettadeit.com/ Baretta DE&IT A division of Baretta SRL tel. +39 02 370 111 55 fax. +39 02 370 111 54 Our technology: The Application System/Xcaml (AS/Xcaml) The FreerP Project