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 695027EE5B for ; Tue, 27 May 2014 12:36:16 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of bmillwood@janestreet.com) identity=pra; client-ip=38.105.200.115; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="bmillwood@janestreet.com"; x-sender="bmillwood@janestreet.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of bmillwood@janestreet.com designates 38.105.200.115 as permitted sender) identity=mailfrom; client-ip=38.105.200.115; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="bmillwood@janestreet.com"; x-sender="bmillwood@janestreet.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@mxout1.mail.janestreet.com) identity=helo; client-ip=38.105.200.115; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="bmillwood@janestreet.com"; x-sender="postmaster@mxout1.mail.janestreet.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8BAOZphFMmachznGdsb2JhbABZhDGCaqpblFABgQUeDgEBAQEBBhYJPIIlAQEBAwESEQQZAQE3AQQLCQIEBw0qAgIiEgEFARwGEyKIDAMJCAMCkzOQD2qKMHeEfwEFmUgihgURBo5SB4J1gUuZd5E2GCmEaQ X-IPAS-Result: Aj8BAOZphFMmachznGdsb2JhbABZhDGCaqpblFABgQUeDgEBAQEBBhYJPIIlAQEBAwESEQQZAQE3AQQLCQIEBw0qAgIiEgEFARwGEyKIDAMJCAMCkzOQD2qKMHeEfwEFmUgihgURBo5SB4J1gUuZd5E2GCmEaQ X-IronPort-AV: E=Sophos;i="4.98,918,1392159600"; d="scan'208";a="64320474" Received: from mxout2.mail.janestreet.com (HELO mxout1.mail.janestreet.com) ([38.105.200.115]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 May 2014 12:36:15 +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 1WpEju-0005lE-0H for caml-list@inria.fr; Tue, 27 May 2014 06:36:14 -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 1WpEjt-00028p-TP for caml-list@inria.fr; Tue, 27 May 2014 06:36:13 -0400 Received: from mail-qg0-f51.google.com ([209.85.192.51]) by mxgoog2.janestreet.com with esmtp (Exim 4.76) (envelope-from ) id 1WpEjt-0003Ld-Rw for caml-list@inria.fr; Tue, 27 May 2014 06:36:13 -0400 Received: by mail-qg0-f51.google.com with SMTP id q107so13485787qgd.24 for ; Tue, 27 May 2014 03:36:13 -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=d1OqUGCLpdvGaYJMoBBMGV6N16y40vbX14TgIHu5R9s=; b=jT8qG6qd5brw4cz+PnAf6XlpY/++UEoruKmmeOtiAJEMrhOnJM8WGpP4/xJhHj1Leb YhnkGQQwKA4U4UiLcLd1xd8aExKN81UWYqn3qxFsdhxrgRXVE/FmaSI9nLciAaO71DhS smmmTnBaQph8/LAJMF/qzN8i9sA0AFd+uj0f8= 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=d1OqUGCLpdvGaYJMoBBMGV6N16y40vbX14TgIHu5R9s=; b=eLYytI7l2oIWhsCwvTm/vDtaqiEj6IpkIdyyH8lYOykVGBcyFjSySEXl+KB2Yfm0RD avhEYGSKPV2LlBFvKq4Q9a9E8LQEMOP5z1KPUlObTSRsIaGJap6rW1eHhWUv1sKs4z8P hcRSY3sFhqSQoQSQoQorzJQv/QsEp5PmfK3rsYtDfJowsbFyjcvu7j87qAv0WQ4u9QZ2 y8TvjUgaRHrGCwIBqJtBdcwm98Cmew1Y6HlPirMd1aBeppfiCZBLmHn9LWkvDhfIKN4b HNLUnjStZYq7W6Z5QI0d6femmuhDe71ChMMf2FYDg9KnsxPNyV+J+/Oz5eAV9j7mQ0/W HrBw== X-Gm-Message-State: ALoCoQnQ3SRI5rMb89T9nhjPngO1CoWfkLIipvVmBJXF4+Zxjjo4TemhThwb3WcNLQX2+Ui//vuskdj3OCffQcno+SKcIrtlc7qtGoNfLPhQtCYsU0L60hPBbtSGhy/yOXISZrrSs2+7 X-Received: by 10.224.161.138 with SMTP id r10mr26161618qax.2.1401186973664; Tue, 27 May 2014 03:36:13 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.161.138 with SMTP id r10mr26161608qax.2.1401186973594; Tue, 27 May 2014 03:36:13 -0700 (PDT) Received: by 10.140.103.67 with HTTP; Tue, 27 May 2014 03:36:13 -0700 (PDT) In-Reply-To: <20140527100540.GC15848@frosties> References: <53835610.9050609@inria.fr> <53B801AD6F5B4BFBA0DA2A69D8775497@erratique.ch> <20140527100540.GC15848@frosties> Date: Tue, 27 May 2014 11:36:13 +0100 Message-ID: From: Ben Millwood To: Goswin von Brederlow Cc: caml users Content-Type: multipart/alternative; boundary=089e014953ecd367a004fa5f4388 Subject: Re: [Caml-list] Uncaught exceptions in function type. --089e014953ecd367a004fa5f4388 Content-Type: text/plain; charset=UTF-8 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. --089e014953ecd367a004fa5f4388 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 2= 7 May 2014 11:05, Goswin von Brederlow <goswin-v-b@web.de> w= rote:
On Tue, May 27, 2014 at 09:4= 2:35AM +0100, Ben Millwood wrote:
> This is essentially why we still have a few Not_found exceptions in Co= re,
> 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 break= age.

HUH?

Say you have a function

val f : ('a, 'b) t -> 'a -> 'b =C2=A0 (raise [Not_fou= nd])

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
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = Goswin

I really mean where we'd= like to change Not_found to a more informative or appropriate exception. S= orry, I forgot about one case where we are completely fine with using excep= tions: in (usually short-lived) programs where the correct behaviour on err= or 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.
--089e014953ecd367a004fa5f4388--