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 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 0241ABC6C for ; Thu, 7 Feb 2008 16:37:52 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAPOzqkfUnw7Wi2dsb2JhbACCN416AQEBCAQGBwgam2c X-IronPort-AV: E=Sophos;i="4.25,316,1199660400"; d="scan'208";a="8919469" Received: from ptb-relay03.plus.net ([212.159.14.214]) by mail3-smtp-sop.national.inria.fr with ESMTP; 07 Feb 2008 16:37:52 +0100 Received: from [80.229.56.224] (helo=beast.local) by ptb-relay03.plus.net with esmtp (Exim) id 1JN8ov-0000TK-SB for caml-list@yquem.inria.fr; Thu, 07 Feb 2008 15:37:51 +0000 From: Jon Harrop Organization: Flying Frog Consultancy Ltd. To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] [OSR] Exceptionless error management, take 2 Date: Thu, 7 Feb 2008 15:33:35 +0000 User-Agent: KMail/1.9.7 References: <1202396482.6084.5.camel@Blefuscu> In-Reply-To: <1202396482.6084.5.camel@Blefuscu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200802071533.35279.jon@ffconsultancy.com> X-Plusnet-Relay: 6858c2fe7bd4655170935f9292868300 X-Spam: no; 0.00; ocaml's:01 inherently:01 ocaml:01 ocaml:01 segfaults:01 merit:98 teeth:98 toilet:98 frog:98 polymorphic:01 polymorphic:01 wrote:01 exception:01 exception:01 caml-list:01 On Thursday 07 February 2008 15:01:22 David Teller wrote: > As it seems that the first take on exceptionless error management has > been discarded, I have put together a second candidate. This proposal > takes into account the discussions from the first candidate, should > resolve the issues introduced by that first candidate -- and presumably > open a few other cans of worms somewhere along the way. There is also some merit in the hierarchical classification of exceptions, e.g. as .NET provides (class hierarchies). For example, you might make Invalid_argument a base exception with derived exceptions for each of the different functions that raise this exception, in order to carry more precise information about what exactly went wrong. OCaml's current approach of conveying a string argument is not in the API and feels unhygienic as a consequence. Like brushing your teeth whilst on the toilet. We all do it, but only because we're in a hurry and not because it is an inherently good idea. Anyway, this can be achieved using variant and polymorphic variant exception arguments in OCaml. However, as Zheng Li pointed out late last year, OCaml is broken with respect to polymorphic variant exception arguments, e.g. this segfaults: exception E of [>];; try raise(E`X) with E`X x-> !x I don't know where the boundary in the language lies, beyond which it is unsafe/wrong, so I think it would be constructive to describe this and your "exception+polymorphic variant"-related proposal seems like a good place to do so. Just an idea... -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/products/?e