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 2AD8E80211 for ; Fri, 20 Oct 2017 12:55:35 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=dra-news@metastack.com; spf=Pass smtp.mailfrom=dra-news@metastack.com; spf=None smtp.helo=postmaster@outmail149082.authsmtp.co.uk Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dra-news@metastack.com) identity=pra; client-ip=62.13.149.82; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of dra-news@metastack.com designates 62.13.149.82 as permitted sender) identity=mailfrom; client-ip=62.13.149.82; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@outmail149082.authsmtp.co.uk) identity=helo; client-ip=62.13.149.82; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="postmaster@outmail149082.authsmtp.co.uk"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3ACIc/mhJizKkwslCBgNmcpTZWNBhigK39O0sv0rFi?= =?us-ascii?q?tYgULv/xwZ3uMQTl6Ol3ixeRBMOAtKIC1rKempujcFJDyK7JiGoFfp1IWk1Nou?= =?us-ascii?q?QttCtkPvS4D1bmJuXhdS0wEZcKflZk+3amLRodQ56mNBX660e/5j8KGxj5KRE9?= =?us-ascii?q?ZqGsQtaT3IyL0LWX8pnYZAFNzB+0fbp2Lxz++QDUv9UfhYhrAqk0wxrN5HBPfr?= =?us-ascii?q?ISjSljLFeX2hL9/duY/Zh58i0Wtehrv5pLWKD+OqA5VqBwDTI8Mmlz6te95jfZ?= =?us-ascii?q?Sg7aynICU2leux5MGA/d9FmuUo349y33qfFV3SSGNNbqRLs3Hz+l6vE4G1fTlC?= =?us-ascii?q?4bOmthoynsgctqgfce+Ur5qg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BEAwD+1OlZh1KVDT5cHAEBBAEBCgEBF?= =?us-ascii?q?QEBAQECAQEBAQgBAQEBgmaBMm4nB48GjktDAQEGgS+YRgojhAMBgRQChDdEEwE?= =?us-ascii?q?BAQEBAQEBAQEBEgEBAQoLCQgoL0IOgWgFAR4BBYI7AQEBBCcTTwIBCA4KHhAyJ?= =?us-ascii?q?QIEARqKCw0BAwELq0U6iyABAQEHAQEBAQEBARwFgy6CB4EJhCaBNIUHg0GCMgW?= =?us-ascii?q?hXIdjjQ4MkxCVSQIECwIagTk3gXs0ISVegmSCbIFzdgGDKIVaRAGBEAEBAQ?= X-IPAS-Result: =?us-ascii?q?A0BEAwD+1OlZh1KVDT5cHAEBBAEBCgEBFQEBAQECAQEBAQg?= =?us-ascii?q?BAQEBgmaBMm4nB48GjktDAQEGgS+YRgojhAMBgRQChDdEEwEBAQEBAQEBAQEBE?= =?us-ascii?q?gEBAQoLCQgoL0IOgWgFAR4BBYI7AQEBBCcTTwIBCA4KHhAyJQIEARqKCw0BAwE?= =?us-ascii?q?Lq0U6iyABAQEHAQEBAQEBARwFgy6CB4EJhCaBNIUHg0GCMgWhXIdjjQ4MkxCVS?= =?us-ascii?q?QIECwIagTk3gXs0ISVegmSCbIFzdgGDKIVaRAGBEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.43,405,1503352800"; d="scan'208";a="241771675" Received: from outmail149082.authsmtp.co.uk ([62.13.149.82]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Oct 2017 12:55:34 +0200 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v9KAtVjh023843; Fri, 20 Oct 2017 11:55:31 +0100 (BST) Received: from romulus.metastack.com (114.212-105-213.static.virginmediabusiness.co.uk [213.105.212.114]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id v9KAtUon056264 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Oct 2017 11:55:31 +0100 (BST) (envelope-from dra-news@metastack.com) Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id v9KAtT7r018185; Fri, 20 Oct 2017 11:55:29 +0100 Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.03.0361.001; Fri, 20 Oct 2017 11:55:29 +0100 From: David Allsopp To: Malcolm Matalka , "caml-list@inria.fr" Thread-Topic: [Caml-list] What if exn was not an open type? Thread-Index: AQHTSYmyBHjAVPaOFUyprpZdd389tKLsjQaQ Date: Fri, 20 Oct 2017 10:55:28 +0000 Message-ID: References: <86o9p2ywgc.fsf@gmail.com> In-Reply-To: <86o9p2ywgc.fsf@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.232.60.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-Server-Quench: 31038667-b585-11e7-8deb-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZZVg1f DC4bFwdFRBksPQFF ChxFJgxfNl8UURhQ KkJXbgASJgdEAnZS R3kJW1VTQFxwU2Zw YQlQIwdcYVRPXwB0 UklLXFNTEBpqBAMA SFgXKWg2EloYeHt2 Z0BmEHFbX0VyO0V8 Qk1cE2sBeDVlYGUC UUENcB5cJFYYYx9F aFV2VCIMZDFWYTQC Ml17DBs4ODEaLCVO XjRFElIbXQ4KEHYx VxZKAjw0VUsCW206 KVQhMlMaVFoAKkhl WQAA X-Authentic-SMTP: 61633634383431.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 213.105.212.114/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Subject: RE: [Caml-list] What if exn was not an open type? Malcolm Matalka wrote: > I have a question in two parts: >=20 > 1. Would this be a good idea? Why? (I'll describe why I think it is) >=20 > 2. If it were a good idea, is it feasible to do? >=20 > Full question: >=20 > Despite exceptions being a part of the language, there is a trend in > many libraries to try to avoid using them. While I cannot find it, I > recall someone (Daniel maybe?) saying that the standard API advice is > that exceptions should not cross API boundaries. >=20 > The short reason for why people seem to want to avoid exceptions (which > I agree with) is that they side step the type system for helping you > understand if your code is correct and handles all situations the code > might experience. Since the exn type is open, it means that one can > add any exception they want so it's not even known what exceptions you > might get ahead of time. >=20 > Another aspect of exceptions, which might be more of my personal > experience, is that exceptions tend to be pretty useless after the > fact. For example, forgetting to handle a Not_found exception is an > exercise in pain. Maybe I'm just bad at this, but many exceptions just > aren't that useful. End_of_file is another one that, IMO, makes the > program flow pretty awkward and if you have multiple files you're > reading from at the same time quite ugly. I tend to use wrappers that > give me an option based API. Maybe I just bad at solving these > problems though and I'm the problem. >=20 > The consequence of this is that even though I put a lot of effort in my > code trying to avoid exceptions, I can never actually know that I have > succeeded unless I'm very defensive and wrap all foreign calls in some > exception handling code. There are APIs for this, but if I mess up > then I'm in a bad spot. >=20 > My proposal is that exceptions becomes a closed type and they reflect > what Java calls "errors", which are things your program logic should > generally not handle but can choose to if it wants to (I think we call > these failures in Ocaml). The two specific exceptions I can think if > that should exist are: Assertion_failure and Out of Memory. Another > one that I think might be nice but is open for debate is a > Not_implemented_failure, I use something like this often while building > a system. I'm sure there are a few more that people can think of are > meaningful, but the point is these represent pretty bad situations that > the program logic shouldn't handle except in special situations. Without wishing to open old debating wounds too much, the argument of excep= tions as errors tends to come down as to whether the thing signalled by an = exception is truly exceptional. Not_found, for example, in some scenarios i= s as unexpected or impossible as Invalid_argument. Historically, they're (a= b)used for performance reasons, but some of the overhead of that is being a= ddressed in flambda. Note that for some arguable design mistakes - e.g. End= _of_file, you can use exception matching to get around this, e.g. match input_line ch with | data -> ... | exception End_of_file -> ... which means that the old pattern let data =3D try Some (input_line ch) with End_of_file -> None is only needed if you need to compile with OCaml < 4.02 If you haven't come across it, https://caml.inria.fr/pub/old_caml_site/ocam= lexc/ocamlexc.htm is an interesting piece of older research around dealing = with handling exceptions. What your proposal does overlook slightly is the use of exceptions for actu= al flow control. See for example, an oldish post of Alain Frisch's at https= ://www.lexifi.com/blog/static-exceptions. However, uses of exceptions like = this may at some point be subsumed by Algebraic Effects which are being wor= ked on by various people, mostly with multicore OCaml in mind. There's lots= of links to that in https://github.com/ocamllabs/ocaml-multicore/wiki as w= ell as other literature elsewhere online. HTH, David=20