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 38C887EE5B for ; Tue, 27 May 2014 10:49:58 +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.11; 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.11; 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.11; 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: Aq0BAEpRhFPU4xELnGdsb2JhbABZsXWUUAGBDxYOAQEBAQEGDQkJFCiCJQEBBAEnCwFLCwsYCSUPBShPiBIBDAzNPx+GUheJM4UmFoMVgRUEmXKGVRKPew X-IPAS-Result: Aq0BAEpRhFPU4xELnGdsb2JhbABZsXWUUAGBDxYOAQEBAQEGDQkJFCiCJQEBBAEnCwFLCwsYCSUPBShPiBIBDAzNPx+GUheJM4UmFoMVgRUEmXKGVRKPew X-IronPort-AV: E=Sophos;i="4.98,917,1392159600"; d="scan'208";a="64300761" Received: from mout.web.de ([212.227.17.11]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 May 2014 10:49:57 +0200 Received: from frosties.localnet ([78.43.112.61]) by smtp.web.de (mrweb101) with ESMTPSA (Nemesis) id 0MWjAd-1XMzVP1Bgh-00XwCO for ; Tue, 27 May 2014 10:49:56 +0200 Received: from mrvn by frosties.localnet with local (Exim 4.82) (envelope-from ) id 1WpD50-0004DB-JU for caml-list@inria.fr; Tue, 27 May 2014 10:49:54 +0200 Date: Tue, 27 May 2014 10:49:54 +0200 From: Goswin von Brederlow To: caml-list@inria.fr Message-ID: <20140527084954.GA15848@frosties> References: <53835610.9050609@inria.fr> <53B801AD6F5B4BFBA0DA2A69D8775497@erratique.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53B801AD6F5B4BFBA0DA2A69D8775497@erratique.ch> User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:QL/fMiKlWCFq9nXFkUgcx+HDehkGed0pE4RFJL3MR2Ue1nltlOy msNvIMKPzzaGSBVcRjqOwbUGqLtzFCv7LyRATWgTUiZP3ANTmoIBirsruiXQmrIMMneVRhO HYzEQSkHQncHwdQzmvEADrM89tMmu4Amh45loOdlsUSmt07HTaz6IXxAIOxvSYrJmt99m7V 19Kcs4+FUrSuKnyQtWl/A== Subject: Re: [Caml-list] Uncaught exceptions in function type. On Mon, May 26, 2014 at 06:34:33PM +0200, Daniel Bünzli wrote: > Le lundi, 26 mai 2014 à 18:02, Philippe Veber a écrit : > > Thanks! BTW core still uses exceptions. Is there an explicit rule as to how to decide between Result type or exceptions. For instance, why not write the Array.create function like this: > > > > val create : int -> 'a -> 'a array Or_error.t > > > > where create fails for a negative integer? > Because that would be utterly annoying. You need to make the > following distinctions: > > * Programming errors, for contracts with the programmer that cannot > be enforced through types. For that raises Invalid_argument if the > contract is violated. Invalid_argument is not supposed to be handled, > it denotes an API misuse, like calling Array.create with a negative > integer. Sometimes arguments are computed and suddenly exceed aceptable parameters. E.g. the user specifies a data file that needs to be read into a string. If the file is too large you get Invalid_argument. Programms can catch and handle such cases, at least to the point of giving a good error message. Idealy a program should catch all exceptions and explain in a human readable way why they happened. > * Exceptional errors, for errors that the programmer is unlikely to > handle at all (e.g. out of memory). For that raise a custom exception. > This should occur very rarely, you are unlikely to ever define one > such exception. Out of memory is probably the only exception you can't do anything about in ocaml. Catching and handling it would nearly always need more ram causing just another Ouf_of_memory exception. In ocaml you are pretty much screwed. > * Non-exceptional errors, errors that the programmer will have to > handle (e.g. failing to connect a socket), for that do not use a > custom exception but use variants or options types. That is a matter of taste and with recursions in the mix exceptions can be a great way to abort the recursion while keeping the code flow simple. They also allow you to use things like List.fold_left and abort early. Variants or option types are not always the best solution. > In general if you write libraries it???s better to err on the side > of exceptionless design: never use exceptions beyond Invalid_argument > (and especially never use Not_found or Failure). Leave exception > definition/usage at the discretion of the user (if he wishes to shoot > himself in the foot). > > Best, > > Daniel MfG Goswin