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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 2EDF280211 for ; Fri, 20 Oct 2017 19:07:29 +0200 (CEST) Authentication-Results: mail2-smtp-roc.national.inria.fr; spf=None smtp.pra=mmatalka@gmail.com; spf=Pass smtp.mailfrom=mmatalka@gmail.com; spf=None smtp.helo=postmaster@mail-pf0-f182.google.com Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of mmatalka@gmail.com) identity=pra; client-ip=209.85.192.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of mmatalka@gmail.com designates 209.85.192.182 as permitted sender) identity=mailfrom; client-ip=209.85.192.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-pf0-f182.google.com) identity=helo; client-ip=209.85.192.182; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="postmaster@mail-pf0-f182.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3Aayzk1RDUBBWes4SwT0P7UyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSP77p8bcNUDSrc9gkEXOFd2Crakb26yL6+jJYi8p39WoiDg6aptCVhsI24?= =?us-ascii?q?09vjcLJ4q7M3D9N+PgdCcgHc5PBxdP9nC/NlVJSo6lPwWB6lX71zMZGw3+OAxp?= =?us-ascii?q?Pay1X9eK14Xkn9y1rrHafQREzBO5Zah1NA3++QnLv4wQjJR5AqM81hLSvnJDeK?= =?us-ascii?q?JdwmY+dnyJmBOpw86095ln9mx1su4o881JGfH/eq0kRLhbBRwpNmk04IvgshyV?= =?us-ascii?q?HljH3WcVTmhDykkAOAPC9hyvG86p6iY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAwAPLOpZf7bAVdFcRwEBBAEBCgEBh?= =?us-ascii?q?BiBFZ1XgXqJOo8OChgLhAMBgRQChDtEEwEBAQEBAQEBAQEBEgEBCQsLCCYxgjg?= =?us-ascii?q?FAR4BBYI7AQEBAQIBASYZARsdAQMBCwYFCwMKCSUPAQQPEQEFASITGoltAQMNC?= =?us-ascii?q?AQMnkFAjXkYBQEcgwkFg2MKGScNWIMBAQEBAQEBAQMBAQEBAQEBARgCAQUJAQi?= =?us-ascii?q?DHIE2UYFQhROKegWhX4djjQ6LWYdGlU0CBAIEBQIGFCSBFTeBezQhCB0VSTWCL?= =?us-ascii?q?4RfdgGJCoFVAQEB?= X-IPAS-Result: =?us-ascii?q?A0AUAwAPLOpZf7bAVdFcRwEBBAEBCgEBhBiBFZ1XgXqJOo8?= =?us-ascii?q?OChgLhAMBgRQChDtEEwEBAQEBAQEBAQEBEgEBCQsLCCYxgjgFAR4BBYI7AQEBA?= =?us-ascii?q?QIBASYZARsdAQMBCwYFCwMKCSUPAQQPEQEFASITGoltAQMNCAQMnkFAjXkYBQE?= =?us-ascii?q?cgwkFg2MKGScNWIMBAQEBAQEBAQMBAQEBAQEBARgCAQUJAQiDHIE2UYFQhROKe?= =?us-ascii?q?gWhX4djjQ6LWYdGlU0CBAIEBQIGFCSBFTeBezQhCB0VSTWCL4RfdgGJCoFVAQE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.43,405,1503352800"; d="scan'208";a="297211726" Received: from mail-pf0-f182.google.com ([209.85.192.182]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 20 Oct 2017 19:07:27 +0200 Received: by mail-pf0-f182.google.com with SMTP id i5so11907314pfe.6 for ; Fri, 20 Oct 2017 10:07:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=LYmmtLcYtu87fvUh8xh80KFWIt76wBc0v3753Kq7o08=; b=Kf0HmKTmm+uTuhWvNLKHNp6J7Ay6EVdF2kXQRUcBf9g6smqW+bo+UcndyGsqMPVvcj BvjoUyiet2OonTY1Ufakb4IUqHXhuZlLtPm+94OwiyU5uMzq+E8NtootLSktUUEOToP4 2eOVE3KsqfRJOD1cl3doaDzwqhLgLyuPZ3yahed/WUFFLVkqxwu7qwELyjkw2NZcjtkN HuDY+ltbG3qRIDbJcucO/2JzrXfaUEXxxGSRs/6JDmQvtla6DFi6MADt6YXAEwGp9QrX HK5IOdpH5V7+TkPxJR35dgpOfEu7MaKt6cI4uylRBxN8fiweoS+Cv0Xc03Tq/KXd0KjW HTUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=LYmmtLcYtu87fvUh8xh80KFWIt76wBc0v3753Kq7o08=; b=XDq/TGZRg37mnWLgVFcnEMiR8p1fhvzHMgfo5Wnj5fGwenuPpz1FqtvA6jvzekF104 YI3ce0EWHg1UjbZwYA0JvqvKfGeFaewNSEuPTHRGvMLrH3vJEfKxeM2oCoTySq34G30T gjR5FJpWiKnQSxpmBwXggTRANO8pde9LgPNrYQ29piy5h6PBaGQSkX+JnPiNL2iKl2Ys GlP+bdE5RVnn67YJjM+Knh9PWxOxXNOHaWlTYnAZKnuoJ4p0fYM02jBvz1jcZuoFKov8 SR/1kEy9fbXG2C/5q5zKLkHAJiTeAlGZw3AssJ52QW6iFzges+/rHPjbujkEpl3MiySn kP7Q== X-Gm-Message-State: AMCzsaVDVKCdkePLOj7uS+g2ZtV+oyugd8JBwQ4sIYA4RDdy76h6iDL3 xPofLgWzPk+f0UGePK9mILo= X-Google-Smtp-Source: ABhQp+QpN6Qp/A0eyn1t7l3al2B6PWr9nj5gYj1/i6HIp+o+FyS/K56xfsbPMrKejQFS2W7dgFupgA== X-Received: by 10.99.2.214 with SMTP id 205mr4963261pgc.375.1508519246008; Fri, 20 Oct 2017 10:07:26 -0700 (PDT) Received: from localhost ([37.153.108.22]) by smtp.gmail.com with ESMTPSA id 62sm2700532pfw.129.2017.10.20.10.07.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 10:07:25 -0700 (PDT) From: Malcolm Matalka To: David Allsopp Cc: "caml-list\@inria.fr" References: <86o9p2ywgc.fsf@gmail.com> Date: Fri, 20 Oct 2017 17:07:22 +0000 In-Reply-To: (David Allsopp's message of "Fri, 20 Oct 2017 10:55:28 +0000") Message-ID: <86fuadzr1x.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Caml-list] What if exn was not an open type? David Allsopp writes: > Malcolm Matalka wrote: >> I have a question in two parts: >> >> 1. Would this be a good idea? Why? (I'll describe why I think it is) >> >> 2. If it were a good idea, is it feasible to do? >> >> Full question: >> >> 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. >> >> 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. >> >> 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. >> >> 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. >> >> 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 exceptions 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 is as unexpected or impossible as > Invalid_argument. Historically, they're (ab)used for performance reasons, but some of the overhead of that is being addressed 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 = 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/ocamlexc/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 actual 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 worked 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 well as other literature elsewhere online. > > HTH, > > > David Thank you for the response and reading material.