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 4F9887EE5B for ; Tue, 27 May 2014 13:24:36 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of yminsky@janestreet.com) identity=pra; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of yminsky@janestreet.com designates 38.105.200.112 as permitted sender) identity=mailfrom; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="yminsky@janestreet.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@mxout1.mail.janestreet.com) identity=helo; client-ip=38.105.200.112; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="yminsky@janestreet.com"; x-sender="postmaster@mxout1.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AloBAC11hFMmachwnGdsb2JhbABQCYQkDYJqqluUUAGBBQgWDgEBAQEBBhYJPIIlAQEBBBIRBBkBATcBDwsLAwoCAiYCAiISAQUBHAYTIogMAxEDAqNTaoowd4R/AQWZSiKGBREGgSqMTVsHgnWBS5l3kTYYKYUE X-IPAS-Result: AloBAC11hFMmachwnGdsb2JhbABQCYQkDYJqqluUUAGBBQgWDgEBAQEBBhYJPIIlAQEBBBIRBBkBATcBDwsLAwoCAiYCAiISAQUBHAYTIogMAxEDAqNTaoowd4R/AQWZSiKGBREGgSqMTVsHgnWBS5l3kTYYKYUE X-IronPort-AV: E=Sophos;i="4.98,918,1392159600"; d="scan'208";a="76613160" Received: from mxout1.mail.janestreet.com ([38.105.200.112]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 May 2014 13:24:35 +0200 Received: from tot-smtp.delacy.com ([172.27.22.15] helo=tot-smtp) by mxout1.mail.janestreet.com with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82) (envelope-from ) id 1WpFUf-0006kW-SP for caml-list@inria.fr; Tue, 27 May 2014 07:24:33 -0400 Received: from tot-dmz-mxgoog1.delacy.com ([172.27.224.14] helo=mxgoog2.janestreet.com) by tot-smtp with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WpFUf-0003s5-Nm for caml-list@inria.fr; Tue, 27 May 2014 07:24:33 -0400 Received: from mail-la0-f45.google.com ([209.85.215.45]) by mxgoog2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1WpFUf-0004ku-Iv for caml-list@inria.fr; Tue, 27 May 2014 07:24:33 -0400 Received: by mail-la0-f45.google.com with SMTP id gl10so6440710lab.18 for ; Tue, 27 May 2014 04:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gc0UFmQhC3mO5Bu3AYmr2htKHI+kfWIqxuGNx+iQWMU=; b=0PPLfM3tdtVKC1HPB8Va8FFtq4DaENvOBZrZASVDvhYapqpZ4R1irYfm/ncFpJhjtR gdl5P4RSzwCfYBNSIIuHtVc1o8KxpEBrLoYKCzQdCKr2qb0DWgjeD8W05MnFZR9YqJHa twoY99upZG41VehSIQoxsnXKLvNNQTOf9jHKg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=gc0UFmQhC3mO5Bu3AYmr2htKHI+kfWIqxuGNx+iQWMU=; b=VhaEt7d59xdhp4YHAdRA8oqA2r3BVVkcIXPYQLGHHtGD3J/WIIGJmz7bEtik5c+Dr/ F3lODRRpNUdjv1AIfw9kpnloumWUn81dP1Xjd65wtPBk0gNrf6V65pGq4fe2/PUzFq51 zx6VAVIhKtwgl477JjT/Xh0rGO30MIZE8JxEVAHScJy/3q1ndjIxmdteEUJ6QOE2mlb3 XffJma3gYk1gKnMkhJ8s6FgeQB2J0Uvwinbj0Vew1Nbmp9/fKXpJPfVZHWzQkqFb7ALt hCJscETTUjB1gNsFxiyOQpSXU1YGL1GGqmquZ/bAbj9d9VR1O7AK/DdAiwdyM3SOVGay pmMQ== X-Gm-Message-State: ALoCoQnMctzm4gD7JTFG3cQ1Fio8ziz0zT9Jgr6Zqty6wvrMwN3Vn/2Pq1vtIBKCiNLhBRlUXI5uCa9BxNZ2p+Wt4D+FZvjTSlxwNWL/2v0Ft1wA24fr8eoAYqW34Jhfh7SooRvmDjOx X-Received: by 10.112.85.167 with SMTP id i7mr21354523lbz.32.1401189872923; Tue, 27 May 2014 04:24:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.85.167 with SMTP id i7mr21354515lbz.32.1401189872835; Tue, 27 May 2014 04:24:32 -0700 (PDT) Received: by 10.112.3.39 with HTTP; Tue, 27 May 2014 04:24:32 -0700 (PDT) In-Reply-To: References: <53835610.9050609@inria.fr> <53B801AD6F5B4BFBA0DA2A69D8775497@erratique.ch> <20140527100540.GC15848@frosties> Date: Tue, 27 May 2014 07:24:32 -0400 Message-ID: From: Yaron Minsky To: Ben Millwood Cc: Goswin von Brederlow , caml users Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Uncaught exceptions in function type. You shouldn't take Ben's comments to indicate that we don't ever throw exceptions. We have lots of functions whose names are explicit about the fact that they throw exceptions, like Map.find_exn or List.last_exn. They have legitimate uses, for example, in contexts where you've checked that the precondition for that function to not throw an exception, and so it would simply be a bug if it were thrown. In those cases, it is indeed hard to change the specific exception that is thrown without potentially breaking external code that depends on it. That's why in new modules, are usual behavior is to not expose the concrete exceptions we declare in the mli of our modules, on the theory that we don't want users of the module to depend on the identity of an exception. y On Tue, May 27, 2014 at 6:36 AM, Ben Millwood wrote: > On 27 May 2014 11:05, Goswin von Brederlow wrote: >> >> On Tue, May 27, 2014 at 09:42:35AM +0100, Ben Millwood wrote: >> > This is essentially why we still have a few Not_found exceptions in >> > Core, >> > because it's really pretty hard to know where they might be relied upon, >> > so >> > it's easier to leave them in than purge them and risk silent breakage. >> >> HUH? >> >> Say you have a function >> >> val f : ('a, 'b) t -> 'a -> 'b (raise [Not_found]) >> >> then eliminating Not_found that function would become >> >> val f : ('a, 'b) t -> 'a -> 'b option >> >> That should fail to compile if the return type is used or a signature >> exists. Where do you think a change would go unnoticed? >> >> MfG >> Goswin > > > I really mean where we'd like to change Not_found to a more informative or > appropriate exception. Sorry, I forgot about one case where we are > completely fine with using exceptions: in (usually short-lived) programs > where the correct behaviour on error is always to explode apologetically > right there and then. The choice of exception is still relevant because it > affects the quality of the backtrace and message.