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 CBDCF80211 for ; Fri, 20 Oct 2017 11:56:10 +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-f172.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.172; 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.172 as permitted sender) identity=mailfrom; client-ip=209.85.192.172; 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-f172.google.com) identity=helo; client-ip=209.85.192.172; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="postmaster@mail-pf0-f172.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3AIdtsHxaPM+k2h5Q9ADk1JQ3/LSx+4OfEezUN459i?= =?us-ascii?q?sYplN5qZpsmybnLW6fgltlLVR4KTs6sC0LWG9f24EUU7or+/81k6OKRWUBEEjc?= =?us-ascii?q?hE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i76vnYuHUD0PA9x?= =?us-ascii?q?Y+D0AZL6jsKt1un09YeATR9PgW+YaLd5KxGz5SDYqsASgoIqfqM0wwfApnhBU+?= =?us-ascii?q?tTzGJsY1mUmkCvtY+L4Jd//nEI6Loa/MlaXPCicg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DVBACyxulZhqzAVdFcGwEBARUBAQEEA?= =?us-ascii?q?QEBCQEBARUBAQEEAQEBhSCdWIs0jwwKhCYBhVhCFQEBAQEBAQEBAQEBEgEBAQg?= =?us-ascii?q?LCwgoL4I4IoMKARseAxIQFjQBBA8RAQUBijwBAxUEnQtAjhEFARyDCQWDYgoZJ?= =?us-ascii?q?w1YgwEMHgIGCQEIgxyCB4FQimSFKQWhXIFukwOLWIdElUkCBAIEBQIGFCSBFTW?= =?us-ascii?q?BfTQhCB0VfoIvgmyBc3aKWAEBAQ?= X-IPAS-Result: =?us-ascii?q?A0DVBACyxulZhqzAVdFcGwEBARUBAQEEAQEBCQEBARUBAQE?= =?us-ascii?q?EAQEBhSCdWIs0jwwKhCYBhVhCFQEBAQEBAQEBAQEBEgEBAQgLCwgoL4I4IoMKA?= =?us-ascii?q?RseAxIQFjQBBA8RAQUBijwBAxUEnQtAjhEFARyDCQWDYgoZJw1YgwEMHgIGCQE?= =?us-ascii?q?IgxyCB4FQimSFKQWhXIFukwOLWIdElUkCBAIEBQIGFCSBFTWBfTQhCB0VfoIvg?= =?us-ascii?q?myBc3aKWAEBAQ?= X-IronPort-AV: E=Sophos;i="5.43,405,1503352800"; d="scan'208";a="297138836" Received: from mail-pf0-f172.google.com ([209.85.192.172]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 20 Oct 2017 11:56:09 +0200 Received: by mail-pf0-f172.google.com with SMTP id b6so10376442pfh.7 for ; Fri, 20 Oct 2017 02:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:user-agent:mime-version; bh=+mXZshlg+OLgVshPgnmrZ2KN2ic3J8OzJFnK070Otmo=; b=GLmgMSrryNknazhMGULkbArEn3SaFqeejwKPzg1fkIT024w3UJwhEvFurc9deqB2Dk RXYh0OzYXqPzU5OyUPGX+KZqC8Ye6VoWxDQbV39F2L1DBkyILK4jJc2Hk1/Wjy2AIDJ6 lQoKRIUzU0hKTUB9XKzyxJGG78pH4wU8+CrguPR7+5xFLacJeu55EdDZXERcemKFC8Je LrEqeKPryjyRKhxPNd4iGKP83AfaY5PBUFGwDw8Yf92pgeXiNTNK661fGcCSS/cM6/OX 949KHJJqPr/8aWEkrL//x9va/D+8QNp29cMowVEaVSmuJl92igYO/3+ir4h1LCGFfNfZ 4JcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:user-agent :mime-version; bh=+mXZshlg+OLgVshPgnmrZ2KN2ic3J8OzJFnK070Otmo=; b=Emchbqpf1HTc8EpJ/iz4fw/pk+nsp7A3UXg0Czk/UTBv+V4aA8VyEuXyL87KgPfmhq hdhZ3UhqBD75aKJQLd8uoeIjTyLhq1CmmMyKgTIwKfIMNvNVH4SjyCdcpfJRpiFwMgws u5/cOzTliqwoMdcwcAJKJ3mWVBdGiCbnSkw1rW6miggqYTORwBA7niov6WbeOOLBlct+ ARYFEPsnzsIbUY6hP3U92kNBltBP36wpE02bojkIYH+pZvoxL1N4rQbAmztqzUlNgfoT DLJSNDIT6iEMzK5FTZXsDLUUqyJliXfrtitiEzSVwcA44GpGrm34TtP4bcn5gwYbKTBt Fe/g== X-Gm-Message-State: AMCzsaUtgvfciC4gT7M3prEy45ALMBOvFrYy+aRHwkLoYgfEY+kKlGzL XFoix6qCJIwcs8YkKfSiMJB+ll0H X-Google-Smtp-Source: ABhQp+TMhgZrGYk07blOd8r754DqBdEHgGSYMZKeRKYLFeLLYIUFA5MlHKY95BD6Z9DsB2izpeo8qQ== X-Received: by 10.101.90.133 with SMTP id c5mr3989437pgt.441.1508493367652; Fri, 20 Oct 2017 02:56:07 -0700 (PDT) Received: from localhost ([37.153.108.22]) by smtp.gmail.com with ESMTPSA id d76sm1401010pfk.69.2017.10.20.02.56.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Oct 2017 02:56:05 -0700 (PDT) From: Malcolm Matalka To: caml-list@inria.fr Date: Fri, 20 Oct 2017 09:56:03 +0000 Message-ID: <86o9p2ywgc.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: [Caml-list] What if exn was not an open type? 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. Thanks for reading, /Malcolm