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 488C37EE5B for ; Tue, 27 May 2014 23:16:25 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of daniel.buenzli@erratique.ch) identity=pra; client-ip=74.55.86.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="daniel.buenzli@erratique.ch"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of daniel.buenzli@erratique.ch) identity=mailfrom; client-ip=74.55.86.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="daniel.buenzli@erratique.ch"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@smtp.webfaction.com) identity=helo; client-ip=74.55.86.74; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="postmaster@smtp.webfaction.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnwBAFr/hFNKN1ZKlWdsb2JhbABZhxuqYpRQAYEkDgEBAQEHDQkJEiqCJQEBBAEjBFIFCwsaAiYCAkcQBhuIMggEsRKkQReBKogJhGwzB4J1NoEVAQOgRxePdg X-IPAS-Result: AnwBAFr/hFNKN1ZKlWdsb2JhbABZhxuqYpRQAYEkDgEBAQEHDQkJEiqCJQEBBAEjBFIFCwsaAiYCAkcQBhuIMggEsRKkQReBKogJhGwzB4J1NoEVAQOgRxePdg X-IronPort-AV: E=Sophos;i="4.98,922,1392159600"; d="scan'208";a="64399555" Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74]) by mail3-smtp-sop.national.inria.fr with ESMTP; 27 May 2014 23:16:23 +0200 Received: from [172.20.10.2] (196-227.197-178.cust.bluewin.ch [178.197.227.196]) by smtp.webfaction.com (Postfix) with ESMTP id 8F5D120E2744; Tue, 27 May 2014 21:16:20 +0000 (UTC) Date: Tue, 27 May 2014 23:16:18 +0200 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Philippe Veber Cc: Ben Millwood , Romain Bardou , caml users Message-ID: <0735CE04495C45A994EE280663B61062@erratique.ch> In-Reply-To: References: <53835610.9050609@inria.fr> <53B801AD6F5B4BFBA0DA2A69D8775497@erratique.ch> X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [Caml-list] Uncaught exceptions in function type. Le mardi, 27 mai 2014 =C3=A0 08:52, Philippe Veber a =C3=A9crit : > - I observed in many libraries (including Xmlm) that people tend to defin= e custom exceptions to signal parsing errors. According to the rules you pr= ovide, parsers should return variants, right? Yes, I was unexeperienced. Also I didn=E2=80=99t understand that the world= was asynchronous at that time. See jsonm for a more sensitive interface. > - as Ben noted earlier, I think point 2 would better be formulated as err= ors that can virtually appear anywhere and/or a programmer cannot do much a= bout (as you say) > - The adjective "exceptional" is a bit misleading IMO, in particular I gu= ess it should not be understood as "not frequent". Rare failures can be ver= y harmful and should be given extra-care since they are not easy to provoke= and debug. Did you mean more like "very abnormal" and so difficult to reco= ver? Well all what you mention seems exceptional to me (at least I wouldn=E2=80= =99t like to work with an API that allows errors to virtually happen everyw= here on a regular basis)=E2=80=A6 But feel free to call that differently.= =20=20 =20=20 > - Another criterion I like is that if checking the precondition of a func= tion f basically amounts (in terms of complexity/algorithm) to calling f, t= hen f shouldn't raise an exception for this precondition. If the preconditi= on is difficult to check, a user is likely not to check it: > - List.find assumes the searched element is in the list, but checking tha= t is precisely what the function is about. Yes, note that finding things in datastructures is pretty clear API wise. U= sually there are two cases 1) the programmer doesn=E2=80=99t if the item is= in the datastructure 2) the programmer knows it=E2=80=99s in there and doe= sn=E2=80=99t want to be annoyed. This leads to 1) val find : t -> key -> value option 2) val get : t -> key -> value (and raises Invalid_argument if the thing is= not in there).=20=20 =20=20 > Having no experience on large projects, it is not clear to me why excepti= ons are considered so dangerous.=20=20 If you don=E2=80=99t/forget to catch the exception at the right place it di= srupts your whole call stack, which means that it breaks any invariants a c= orrect 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=E2=80=99t partially (invariant wise) persist anything to dis= k/network meanwhile. Best, Daniel