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 0D68980211 for ; Sun, 22 Oct 2017 14:39:34 +0200 (CEST) Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=mmatalka@gmail.com; spf=Pass smtp.mailfrom=mmatalka@gmail.com; spf=None smtp.helo=postmaster@mail-pg0-f46.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of mmatalka@gmail.com) identity=pra; client-ip=74.125.83.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="mmatalka@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of mmatalka@gmail.com designates 74.125.83.46 as permitted sender) identity=mailfrom; client-ip=74.125.83.46; receiver=mail3-smtp-sop.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 (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-pg0-f46.google.com) identity=helo; client-ip=74.125.83.46; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mmatalka@gmail.com"; x-sender="postmaster@mail-pg0-f46.google.com"; x-conformance=sidf_compatible IronPort-PHdr: =?us-ascii?q?9a23=3A1eZ5vxNS8TcvJaGHJmkl6mtUPXoX/o7sNwtQ0KIM?= =?us-ascii?q?zox0KP3zrarrMEGX3/hxlliBBdydsK0UzbeO+4nbGkU+or+5+EgYd5JNUxJXwe?= =?us-ascii?q?43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6aijSI4DUTAhTyMxZu?= =?us-ascii?q?bqSwQ9aKzpeB7P2p45DYfylPgTO8Z/sycET3/k3tsZwwiJdiI6B57xzTr3JVM7?= =?us-ascii?q?BQzH9oLFTVmhHm686t1Js/42JXof13pOBaVqCvWq08RrtcCXwDOnw84M7i/U3G?= =?us-ascii?q?SAKT738fW00ZlxNJB07O6xSsDcS5iTfzqucogHrSBsbxV71hHGn74g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLAQDckOxZhi5TfUpcHAEBBAEBCgEBF?= =?us-ascii?q?gEBAQMBAQEJAQEBhBiBFZ1WgXqCUZV5CiOEAwGBFAKEPEMUAQEBAQEBAQEBAQE?= =?us-ascii?q?SAQEBCAsLCCgvgjgFAR4GgjsBAQEBAgEnGQEbEgsBAwELBgULDQkEIQ8BBA0CE?= =?us-ascii?q?QEFAQoYExIHiW4BAw0IBAyeQECNeRgFARyDCQWDVgoZJwMKWIMBAQEBAQEBBAE?= =?us-ascii?q?BAQEBAQEBGAIGCQEIgxyBNlGBUIUTgl6CC4YRBYg3DJhnPIdkiBeEeYJyiGmHR?= =?us-ascii?q?o0MiEMCBAIEBQIGFCSBFTaBfDQhCB0VSTWCLwmCRA4BEAyBZ3aJDoFVAQEB?= X-IPAS-Result: =?us-ascii?q?A0BLAQDckOxZhi5TfUpcHAEBBAEBCgEBFgEBAQMBAQEJAQE?= =?us-ascii?q?BhBiBFZ1WgXqCUZV5CiOEAwGBFAKEPEMUAQEBAQEBAQEBAQESAQEBCAsLCCgvg?= =?us-ascii?q?jgFAR4GgjsBAQEBAgEnGQEbEgsBAwELBgULDQkEIQ8BBA0CEQEFAQoYExIHiW4?= =?us-ascii?q?BAw0IBAyeQECNeRgFARyDCQWDVgoZJwMKWIMBAQEBAQEBBAEBAQEBAQEBGAIGC?= =?us-ascii?q?QEIgxyBNlGBUIUTgl6CC4YRBYg3DJhnPIdkiBeEeYJyiGmHRo0MiEMCBAIEBQI?= =?us-ascii?q?GFCSBFTaBfDQhCB0VSTWCLwmCRA4BEAyBZ3aJDoFVAQEB?= X-IronPort-AV: E=Sophos;i="5.43,417,1503352800"; d="scan'208";a="241924129" Received: from mail-pg0-f46.google.com ([74.125.83.46]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 22 Oct 2017 14:39:31 +0200 Received: by mail-pg0-f46.google.com with SMTP id g6so9802414pgn.6 for ; Sun, 22 Oct 2017 05:39:31 -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=QLjFEjSONwUFcZlePksdb9goluuXbYW1XBHiWb9Iuis=; b=kO0OzgnH+/7hvLElb0ZiNUHcOjskUUf3djdZX/lKe2eMCwDR8eP6oUZA8cMNg7Z+Ts C2DHUAmukj62oZQpJqSl2lh3ndeQxH9ipa6+xp5GnZtcgOgh2iFjd4fWN5DrwL7oEvwx 2E3EVpLk2mUpgY4xIrpq6c3Magm2Sxh9wJTCWvc36kmirXP/TciLHes29b8JjfZmYAiO 4CKJBqPdpXyQj3UylvLtCvlgbr7Ab85E01CThKMu5O0/RwDuv5KNNu4Bc8G0do0rNsgY DTYFlFnga/6K4eyU3p+Y+jIQj6uC7xCnrzQ4oaej2vUuGuwZ3PFn1Pk5FjkdOzfsf8DN 2Ptg== 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=QLjFEjSONwUFcZlePksdb9goluuXbYW1XBHiWb9Iuis=; b=K148Xc8JmotUBMXhfTA/csTizP2WffriVthyNz4TRU3oKsth1MYNp3JLaYUuW7j+TF PNwxPVvd8eLujOinxjaCDR46KJuz6+6P/W9m04FgHWqm/PiyppF2bETXMq0ucw1QNlr2 LpSbSWi7Mv4fA4lojA6iZv9xy5XGcHA5UUznCTaeweqjT5+OIoTsh4Fw0LUpPD8FAAC8 y4QKD23nmX3WdsaDNqSq/GvFgqHw55Veo8UQFR6IriZ7ImKI5W+rEgdLSDxOUMvwWCRQ SnqdW7610F0aE4SSY+1jH2cmQPFVpRNdNsZxl7vJJ4c5iz2xQXpH9JWdpVAxyVdzL2Ag 9IEQ== X-Gm-Message-State: AMCzsaVmMYd7RJp+wp49gAIUG3swYVpAW91kc7HAUnJwuJYnxUw68kGt T+ijLxY20Lzy8vOpGckOFlo= X-Google-Smtp-Source: ABhQp+SNiMkwlS91tK3dhw9I8VkABrM3zKpoIleG2X8J5Fcji26srLY6GSNLXPy62VMTynWzmafp5g== X-Received: by 10.101.64.4 with SMTP id f4mr8876640pgp.301.1508675969991; Sun, 22 Oct 2017 05:39:29 -0700 (PDT) Received: from localhost ([37.153.108.22]) by smtp.gmail.com with ESMTPSA id n62sm8926115pfh.95.2017.10.22.05.39.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 22 Oct 2017 05:39:28 -0700 (PDT) From: Malcolm Matalka To: Nathan Moreau Cc: caml users References: <86o9p2ywgc.fsf@gmail.com> Date: Sun, 22 Oct 2017 12:39:25 +0000 In-Reply-To: (Nathan Moreau's message of "Sat, 21 Oct 2017 23:28:18 +0200") Message-ID: <867evnz79e.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? Nathan Moreau writes: > Exceptions being an open type allows you to classify failures. > > from Unix.ml: > > let rec waitpid_non_intr pid = > try waitpid [] pid > with Unix_error (EINTR, _, _) -> waitpid_non_intr pid > > With a closed type, there is not much you can do to ensure that you > catch the right type of exception here (matching on strings? seems > much worse). I'm one of those people that uses result everywhere + result monad where the error case is a polymorphic variant. This lets me get the value of an open type with power of an exhaustive pattern match check. No strings needed. > > Note that, as there is no break keyword in the language, you tend to > use exceptions for control flow to avoid rewriting your for loops to > while loops. This is exactly what monads and applicatives give you: a way to short circuit computation when it's no longer needed. > > You can write some APIs without exposing exceptions, the same way that > you can write an API without exposing a global hash-table. I'm not sure what you mean here, I have not had to expose exceptions in any APIs I've written. I don't think they are bad APIs. > > Exceptions are just a tool, that allow you to work around some > limitations / performance issues / make your life easier. Removing > them is impossible at this point for compatibility reasons, so all you > can do is avoid using them if it makes you sad (the same way you avoid > using some parts of the language when you program in c++ / ecmascript > / whatever language du jour). My point is that I cannot avoid exceptions without being very defensive in my code. A dependency can always start throwing an exception and I have no tool to help me find that automatically. > > Nathan > > > On 20 October 2017 at 11:56, 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. >> >> Thanks for reading, >> /Malcolm >> >> -- >> Caml-list mailing list. Subscription management and archives: >> https://sympa.inria.fr/sympa/arc/caml-list >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs