From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 3236E7F8FE for ; Mon, 2 Jun 2014 10:38:05 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=pra; client-ip=212.227.17.12; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of goswin-v-b@web.de) identity=mailfrom; client-ip=212.227.17.12; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="goswin-v-b@web.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mout.web.de) identity=helo; client-ip=212.227.17.12; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="goswin-v-b@web.de"; x-sender="postmaster@mout.web.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoMBAAA3jFPU4xEMnGdsb2JhbABZxwUBgRIWDgEBAQEBBg0JCRQogiUBAQUyAVYLGAklDwUoiGEBGM1VH4Y8F45ZFoMVgRUEmX+GVxKPfw X-IPAS-Result: AoMBAAA3jFPU4xEMnGdsb2JhbABZxwUBgRIWDgEBAQEBBg0JCRQogiUBAQUyAVYLGAklDwUoiGEBGM1VH4Y8F45ZFoMVgRUEmX+GVxKPfw X-IronPort-AV: E=Sophos;i="4.98,955,1392159600"; d="scan'208";a="64987039" Received: from mout.web.de ([212.227.17.12]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Jun 2014 10:38:04 +0200 Received: from frosties.localnet ([78.43.112.61]) by smtp.web.de (mrweb003) with ESMTPSA (Nemesis) id 0MVLY6-1XJRv31Cow-00YgEO for ; Mon, 02 Jun 2014 10:38:03 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.82) (envelope-from ) id 1WrNkn-00006P-VV for caml-list@inria.fr; Mon, 02 Jun 2014 10:38:02 +0200 Date: Mon, 2 Jun 2014 10:38:01 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20140602083801.GB32010@frosties> References: <53835610.9050609@inria.fr> <53B801AD6F5B4BFBA0DA2A69D8775497@erratique.ch> <0735CE04495C45A994EE280663B61062@erratique.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0735CE04495C45A994EE280663B61062@erratique.ch> User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:8zftard4fCSl5qKKOC8oN+Y+BLJEB4pHKZmZM9UPn2DQvDuo3h3 OWuQ/vG40yNHvar0n2qmkLuc1X8uj+/FLNlq7WE9tfapHDP2K9287woBXYojcgeYi02gRax nU23RE8JovSa1jiOUWylZuZC6SaJo/X+5+QX91JFPRqRc8W5QlehWPgKzco2D5D81QPMtoq 5SE6f1f08W8o913OklC1w== Subject: Re: [Caml-list] Uncaught exceptions in function type. On Tue, May 27, 2014 at 11:16:18PM +0200, Daniel Bünzli wrote: > Le mardi, 27 mai 2014 à 08:52, Philippe Veber a écrit : > > Having no experience on large projects, it is not clear to me why > > exceptions are considered so dangerous. > > If you don???t/forget to catch the exception at the right place it > disrupts your whole call stack, which means that it breaks any > invariants a correct excecution of your call stack was supposed to > maintain. Which means that your program state is completely broken and > you have to exit 1, hoping that you didn???t partially (invariant > wise) persist anything to disk/network meanwhile. > > Best, > > Daniel Which is where tracking exceptions in the type of a functions would come in handy. If you write code that must not be aborted then you annotate the type to throw no exceptions. The type inference would then check that that is the case and give you a compile error otherwise. That way there couldn't be any surprises of an exception breaking your call stack. Also note, even though YOU don't use exceptions doesn't mean some module you use doesn't. With exception part of a functions type this would be exposed in the interface and you can deal with it accordingly (worst case rewrite the module :). So I think you should be all for having exceptions in the type especially because you don't like them. MfG Goswin