From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hrafaelsen@gmail.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by yquem.inria.fr (Postfix) with ESMTP id 439E5BC57
	for <caml-list@yquem.inria.fr>; Wed, 26 May 2010 18:15:06 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuMCAKbl/EtKfVK2imdsb2JhbACSDIwECBUBAQETDBgisXKCAYVFLohPAQEDBYUOBA
X-IronPort-AV: E=Sophos;i="4.53,304,1272837600"; 
   d="scan'208";a="60077544"
Received: from mail-wy0-f182.google.com ([74.125.82.182])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 26 May 2010 18:15:06 +0200
Received: by wyj26 with SMTP id 26so1398180wyj.27
        for <caml-list@inria.fr>; Wed, 26 May 2010 09:15:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:received:date:message-id
         :subject:from:to:content-type;
        bh=1uoFGwjXD146S6a0X2JXMfcAVNG0nF6CD8gUwot2aZo=;
        b=HSe1F0QYyCbI06j89nUtb8DJ5gzJNXa3Ur3Q4kfuKr/J/tAWbMUgdG24SS9+7coS/y
         NG6L6uNYUED2djPV8/Q3tJIucGd+dbNnKUx+IN6YJ6cFd60oe4XXis/63ET0Y/rlKKML
         wcf4nS5JWJxHufFxlYT5jWH9C0IYl0SZkysrw=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=hhmuHh7yh/JPJphNOqlZCtwLl7Xb3fBOLo4nU+nAKEBnhaxLtSTiWj7h6bTR08y887
         jleTYZfKTaE2DUmLR/U6IzSoWaQ669P0E2YO1arwcwolZB92uJXNsxiEUx+uDeeEhJlJ
         1govPy1sarKC+0GyWZohibqrXv697NClo211Q=
MIME-Version: 1.0
Received: by 10.216.88.211 with SMTP id a61mr5518583wef.65.1274890505227; Wed, 
	26 May 2010 09:15:05 -0700 (PDT)
Received: by 10.216.0.71 with HTTP; Wed, 26 May 2010 09:15:05 -0700 (PDT)
Date: Wed, 26 May 2010 18:15:05 +0200
Message-ID: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com>
Subject: Static exception analysis or alternative to using exceptions
From: Hans Ole Rafaelsen <hrafaelsen@gmail.com>
To: caml-list@inria.fr
Content-Type: multipart/alternative; boundary=0016e6d99a45b1141204878193da
X-Spam: no; 0.00; rafaelsen:01 uncaught:01 ocamlexc:01 ocamlexc:01 ocaml:01 monads:01 rafaelsen:01 uncaught:01 ocaml:01 monads:01 exception:01 exception:01 exceptions:01 exceptions:01 caml:02 

--0016e6d99a45b1141204878193da
Content-Type: text/plain; charset=ISO-8859-1

Hi,

when running server software, it is quite frustrating when the program
crashes due to an uncaught exception. I see there was some attempts on doing
static analysis of the exception flow in programs around 10 years ago (such
as ttp://pauillac.inria.fr/caml/ocamlexc/ocamlexc.htm), but they did not
seem to be complete and now seem to be dropped. Is there some technical
reason for not having static exception analyses, or can we hope that some
day in the future, Ocaml will support static exception analysis?

What experience does people have to using alternatives to exceptions, such
as option types or exception monads? Does use of third part libraries that
still throws exceptions make such approaches hard to use? Performance wise
it seems to be comparable to catching exceptions or matching for options, so
I guess the difference be might a question of programming style?


Thanks,

Hans Ole Rafaelsen

--0016e6d99a45b1141204878193da
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<br><br>when running server software, it is quite frustrating when the p=
rogram crashes due to an uncaught exception. I see there was some attempts =
on doing static analysis of the exception flow in programs around 10 years =
ago (such as ttp://<a href=3D"http://pauillac.inria.fr/caml/ocamlexc/ocamle=
xc.htm">pauillac.inria.fr/caml/ocamlexc/ocamlexc.htm</a>), but they did not=
 seem to be complete and now seem to be dropped. Is there some technical re=
ason for not having static exception analyses, or can we hope that some day=
 in the future, Ocaml will support static exception analysis?<br>
<br>What experience does people have to using alternatives to exceptions, s=
uch as option types or exception monads? Does use of third part libraries t=
hat still throws exceptions make such approaches hard to use? Performance w=
ise it seems to be comparable to catching exceptions or matching for option=
s, so I guess the difference be might a question of programming style?<br>
<br><br>Thanks,<br><br>Hans Ole Rafaelsen<br>

--0016e6d99a45b1141204878193da--


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <darioteixeira@yahoo.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by yquem.inria.fr (Postfix) with ESMTP id 8BC0FBC57
	for <caml-list@yquem.inria.fr>; Wed, 26 May 2010 19:30:43 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgQEALP3/EtDww+jdWdsb2JhbACDF4UuiRqDL4khARcgBR+xOzmCAYVHiH0BBAQBgSCDBGoEg0I
X-IronPort-AV: E=Sophos;i="4.53,304,1272837600"; 
   d="scan'208";a="51259385"
Received: from web111506.mail.gq1.yahoo.com ([67.195.15.163])
  by mail3-smtp-sop.national.inria.fr with SMTP; 26 May 2010 19:30:42 +0200
Received: (qmail 85249 invoked by uid 60001); 26 May 2010 17:30:41 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1274895040; bh=AxAG9BOuZxxaYV2mC7//BFL6kZ4v9DdJJYoocepMjn4=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=v1zhxxzfnr9hFmBtdUaJEoZQycEP46rRt/Axa9lBN/+Ms0zZP07gQ4AlaSa9E/MdYyou8HMLou0zdogUBxjm6ffRyKOh8n0uFVcvEOCJzN/0yg7/CeQVYxqrjlCHXRloekXXgzU31qxFvt1M0nDDL0HReS14lQvA0QA6xirEbR0=
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=iqNdi+PYGVC3eDPSe2Nn0JDMjyxCm7FTBQkn3ZhPAdGInSLCJvCIysza44/Tn3yKdCtjdk0MkB+MPNhg3K8+INn6oVYsP1uma2kVZOEowkuqIxs2u6O1rIA8cjiAm3/0zfGF3VENt7BdBw6qzQBztGqRmeZoWI7JswSO8o8HUUs=;
Message-ID: <956439.81564.qm@web111506.mail.gq1.yahoo.com>
X-YMail-OSG: jDRGZckVM1mCQb6_mDBqb75CCMl0uL6i8NTt7jVla4FY.Z_
 IccCZeAUkqRgu4rWbET.PJo.kDVHfkc8jFBKV7FOFkiTuAXvRQS.YrCxzxd_
 sJci5S6D.3McAd9aaScs80izPT_p2PCtLRdeZi4MbQwVoG3ztL89N7963ZR4
 9R_fhjkSy6DMC_H93sBohWuWkmvsbS.Rw5CzP9eRsHodsEa.y5NXOquBnKkH
 gluOA7SjClxaN0QgfU9PQAOSYYi2ouyQB6rIAHB4TdQjT7wSiutiBpJoMdjL
 tQdQZS0HpNJG8Jv.tSFLZzyQSbWG6mDCrPeIh4G.OOfFpxUd64RK6O1U04Wk
 6OAfEUtyRBAPyDuNiTRxc2ERW1TYmQyJy
Received: from [213.205.71.59] by web111506.mail.gq1.yahoo.com via HTTP; Wed, 26 May 2010 10:30:40 PDT
X-Mailer: YahooMailClassic/11.0.8 YahooMailWebService/0.8.103.269680
Date: Wed, 26 May 2010 10:30:40 -0700 (PDT)
From: Dario Teixeira <darioteixeira@yahoo.com>
Subject: Re: [Caml-list] Static exception analysis or alternative to using exceptions
To: Hans Ole Rafaelsen <hrafaelsen@gmail.com>
Cc: caml-list@yquem.inria.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam: no; 0.00; monads:01 ocaml:01 runtime:01 stdlib:01 invoke:01 exception:01 exception:01 caml-list:01 functions:01 functions:01 exceptions:01 exceptions:01 explicitly:02 btw:03 seems:03 

Hi,=0A=0A> What experience does people have to using alternatives to except=
ions,=0A> such as option types or exception monads? Does use of third part=
=0A> libraries that still throws exceptions make such approaches hard to us=
e?=0A> Performance wise it seems to be comparable to catching exceptions or=
=0A> matching for options, so I guess the difference be might a question of=
=0A> programming style?=0A=0APartly yes, though I would say that in Ocaml i=
t is tempting to use=0Aexceptions beyond what is reasonable, because they a=
re so cheap and=0Aconvenient.  As you noted, this can lead to trouble at ru=
ntime, which=0Ais why some libraries discourage the "exceptional style", pr=
eferring=0Aoption types and forcing users to invoke functions suffixed by "=
_exc"=0Aif they really want to use the exception-based version.=0A=0APerson=
ally, I think the litmus test hinges on whether the supposedly=0Aexceptiona=
l situation is truly worthy of the name.  If it's a common=0Aoccurrence, pe=
rhaps one should reconsider the use of an "exception".=0AWithout meaning to=
 start an holy war, let me just add that even on=0Athe Stdlib there are fun=
ctions (such as Map.S.find) that raise an=0Aexception but which should perh=
aps return an option type.=0A=0ABtw, you didn't mention it explicitly in yo=
ur message, but I trust you=0Aare familiar with "Catch me if you can"? [1]=
=0A=0ABest regards,=0ADario Teixeira=0A=0A[1] http://dutherenverseauborddel=
atable.wordpress.com/downloads/exception-monads-for-ocaml/=0A=0A=0A=0A     =
 


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hrafaelsen@gmail.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by yquem.inria.fr (Postfix) with ESMTP id CDDADBC57
	for <caml-list@yquem.inria.fr>; Wed, 26 May 2010 23:10:02 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqAGAMsq/UtKfVKsXmdsb2JhbACIRYkdMIwDCAsgEhAFH7FaggGFQS6ITwEBAwWFDgQ
X-IronPort-AV: E=Sophos;i="4.53,306,1272837600"; 
   d="scan'208";a="60089826"
Received: from mail-wy0-f172.google.com ([74.125.82.172])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 26 May 2010 23:10:01 +0200
Received: by wye20 with SMTP id 20so60191wye.3
        for <caml-list@yquem.inria.fr>; Wed, 26 May 2010 14:10:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:received:in-reply-to
         :references:date:message-id:subject:from:to:cc:content-type;
        bh=ZanDgDxncT8fRBNfhJQU6S+CISSyzTGyGjI9wr+lbmg=;
        b=voXL9VkLN8QmU6XrnJMGsXQp0ceSPfO1HVhCI4L2kBD/G0hqoV29FIzxu2DQIgcUty
         eixBwdIWnuj+hqq1R9F5al0ORanXx6qllV2Q7ozpiU/WahTwW6Dy3emPAiDuy3qQow6j
         2h7sqTvTPPJtcDvuAB39u8YK+LTfiLP80x8Ug=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=BlwKcYxo/5cCBOR0D6JplmIeFBX75ijO+QOjrJeTAm1u7JMfvh+ghMqU+GdgLd25iP
         kKGRIstmqVICRepyGdJaz2pxkHNysoPLbUPhNtoTr843Y3IJlX1thx/MYPZ1cv5TcsFO
         Kx2T6BsyUTARf1qmUoIbqlr3Q1uQmd/u63S8U=
MIME-Version: 1.0
Received: by 10.216.163.204 with SMTP id a54mr113433wel.2.1274908201199; Wed, 
	26 May 2010 14:10:01 -0700 (PDT)
Received: by 10.216.0.71 with HTTP; Wed, 26 May 2010 14:10:01 -0700 (PDT)
In-Reply-To: <956439.81564.qm@web111506.mail.gq1.yahoo.com>
References: <956439.81564.qm@web111506.mail.gq1.yahoo.com>
Date: Wed, 26 May 2010 23:10:01 +0200
Message-ID: <AANLkTimoO4s4ufCPatanWi02vQgNwpUmEAggcdjdcrTf@mail.gmail.com>
Subject: Re: [Caml-list] Static exception analysis or alternative to using 
	exceptions
From: Hans Ole Rafaelsen <hrafaelsen@gmail.com>
To: Dario Teixeira <darioteixeira@yahoo.com>
Cc: caml-list@yquem.inria.fr
Content-Type: multipart/alternative; boundary=0016367f9f6e742a10048785b218
X-Spam: no; 0.00; rafaelsen:01 monads:01 ocaml:01 runtime:01 stdlib:01 syntax:01 monads:01 ocaml:01 runtime:01 stdlib:01 syntax:01 26,:98 26,:98 invoke:01 invoke:01 

--0016367f9f6e742a10048785b218
Content-Type: text/plain; charset=ISO-8859-1

On Wed, May 26, 2010 at 7:30 PM, Dario Teixeira <darioteixeira@yahoo.com>wrote:

> Hi,
>
> > What experience does people have to using alternatives to exceptions,
> > such as option types or exception monads? Does use of third part
> > libraries that still throws exceptions make such approaches hard to use?
> > Performance wise it seems to be comparable to catching exceptions or
> > matching for options, so I guess the difference be might a question of
> > programming style?
>
> Partly yes, though I would say that in Ocaml it is tempting to use
> exceptions beyond what is reasonable, because they are so cheap and
> convenient.  As you noted, this can lead to trouble at runtime, which
> is why some libraries discourage the "exceptional style", preferring
> option types and forcing users to invoke functions suffixed by "_exc"
> if they really want to use the exception-based version.
>
> Personally, I think the litmus test hinges on whether the supposedly
> exceptional situation is truly worthy of the name.  If it's a common
> occurrence, perhaps one should reconsider the use of an "exception".
> Without meaning to start an holy war, let me just add that even on
> the Stdlib there are functions (such as Map.S.find) that raise an
> exception but which should perhaps return an option type.
>
> Btw, you didn't mention it explicitly in your message, but I trust you
> are familiar with "Catch me if you can"? [1]
>
I have just read about it, not tested it yet. Do you have any experience
using this library, especially together with other libraries that also
provides syntax extension?


>
> Best regards,
> Dario Teixeira
>
> [1]
> http://dutherenverseauborddelatable.wordpress.com/downloads/exception-monads-for-ocaml/
>
>
>
>
> Thanks,

Hans Ole

--0016367f9f6e742a10048785b218
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class=3D"gmail_quote">On Wed, May 26, 2010 at 7:30 PM, Dario T=
eixeira <span dir=3D"ltr">&lt;<a href=3D"mailto:darioteixeira@yahoo.com">da=
rioteixeira@yahoo.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 2=
04, 204); padding-left: 1ex;">
Hi,<br>
<br>
&gt; What experience does people have to using alternatives to exceptions,<=
br>
&gt; such as option types or exception monads? Does use of third part<br>
&gt; libraries that still throws exceptions make such approaches hard to us=
e?<br>
&gt; Performance wise it seems to be comparable to catching exceptions or<b=
r>
&gt; matching for options, so I guess the difference be might a question of=
<br>
&gt; programming style?<br>
<br>
Partly yes, though I would say that in Ocaml it is tempting to use<br>
exceptions beyond what is reasonable, because they are so cheap and<br>
convenient. =A0As you noted, this can lead to trouble at runtime, which<br>
is why some libraries discourage the &quot;exceptional style&quot;, preferr=
ing<br>
option types and forcing users to invoke functions suffixed by &quot;_exc&q=
uot;<br>
if they really want to use the exception-based version.<br>
<br>
Personally, I think the litmus test hinges on whether the supposedly<br>
exceptional situation is truly worthy of the name. =A0If it&#39;s a common<=
br>
occurrence, perhaps one should reconsider the use of an &quot;exception&quo=
t;.<br>
Without meaning to start an holy war, let me just add that even on<br>
the Stdlib there are functions (such as Map.S.find) that raise an<br>
exception but which should perhaps return an option type.<br>
<br>
Btw, you didn&#39;t mention it explicitly in your message, but I trust you<=
br>
are familiar with &quot;Catch me if you can&quot;? [1]<br></blockquote><div=
>I have just read about it, not tested it yet. Do you have any experience u=
sing this library, especially together with other libraries that also provi=
des syntax extension?<br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt 0pt 0.8=
ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Best regards,<br>
Dario Teixeira<br>
<br>
[1] <a href=3D"http://dutherenverseauborddelatable.wordpress.com/downloads/=
exception-monads-for-ocaml/" target=3D"_blank">http://dutherenverseaubordde=
latable.wordpress.com/downloads/exception-monads-for-ocaml/</a><br>
<br>
<br>
<br>
<br>
</blockquote></div>Thanks,<br><br>Hans Ole<br>

--0016367f9f6e742a10048785b218--


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rathereasy@gmail.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104])
	by yquem.inria.fr (Postfix) with ESMTP id 79007BC57
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 05:37:53 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmQDAH+F/UtKfVI0mGdsb2JhbACIRYkkMIwFCBUBAQEBAREMBxEisA6CAYVCLohPAQEDBYUOBA
X-IronPort-AV: E=Sophos;i="4.53,308,1272837600"; 
   d="scan'208";a="51274963"
Received: from mail-ww0-f52.google.com ([74.125.82.52])
  by mail3-smtp-sop.national.inria.fr with ESMTP; 27 May 2010 05:37:53 +0200
Received: by wwg30 with SMTP id 30so507146wwg.39
        for <caml-list@yquem.inria.fr>; Wed, 26 May 2010 20:37:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:received:in-reply-to
         :references:date:message-id:subject:from:to:cc:content-type;
        bh=YIjCJ28gPFcZGYzu+TneMyC7XnyOy5mJEUXEdRelh9o=;
        b=S9NHAdcJ9DTr38JhEslSf1zFjn5QlSkcer2OBjgai0wyCRGvTC0jEBYA5NoVS4PzAO
         8L4Rz1YXRP9nQYdY/U5J2vnIabO4cb4tEQjVZV3XV/wmMphB9Qq+qJuB7alwMNhIfSNA
         sRNZ8vITs1WO1IDvcyDi+NrfkcwgqGGx5VMY8=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=c8vrjmMTqIYVkbgIZBzYBKIY82E8B9I8F6eyBBaVz06XLx2ishg+RlLwOHyo8XU2lK
         vDIwzqvubnQ9Z4fofpIakMiePvdEhumxL468ACuWpX/XhKoeeSaDYpnZwVHQq3Sb06A8
         V4iFUEDU/cGNBizCNdFCyn3U4qh0SS83frmfI=
MIME-Version: 1.0
Received: by 10.216.85.68 with SMTP id t46mr263520wee.75.1274931472318; Wed, 
	26 May 2010 20:37:52 -0700 (PDT)
Received: by 10.216.27.72 with HTTP; Wed, 26 May 2010 20:37:52 -0700 (PDT)
In-Reply-To: <AANLkTimoO4s4ufCPatanWi02vQgNwpUmEAggcdjdcrTf@mail.gmail.com>
References: <956439.81564.qm@web111506.mail.gq1.yahoo.com>
	<AANLkTimoO4s4ufCPatanWi02vQgNwpUmEAggcdjdcrTf@mail.gmail.com>
Date: Wed, 26 May 2010 23:37:52 -0400
Message-ID: <AANLkTinyHHP3G3or75nMi2vH5K-8BoBX5cruJ110qqT2@mail.gmail.com>
Subject: Re: [Caml-list] Static exception analysis or alternative to using 
	exceptions
From: Jacques Le Normand <rathereasy@gmail.com>
To: Hans Ole Rafaelsen <hrafaelsen@gmail.com>
Cc: Dario Teixeira <darioteixeira@yahoo.com>,
	caml-list@yquem.inria.fr
Content-Type: multipart/alternative; boundary=0016e6d645a885417e04878b1d81
X-Spam: no; 0.00; rafaelsen:01 monads:01 ocaml:01 runtime:01 stdlib:01 syntax:01 beginner's:01 ocaml:01 bug:01 rafaelsen:01 monads:01 runtime:01 stdlib:01 syntax:01 beginner's:01 

--0016e6d645a885417e04878b1d81
Content-Type: text/plain; charset=ISO-8859-1

Jane Street's Core seems to prefer options to exceptions

On Wed, May 26, 2010 at 5:10 PM, Hans Ole Rafaelsen <hrafaelsen@gmail.com>wrote:

>
>
> On Wed, May 26, 2010 at 7:30 PM, Dario Teixeira <darioteixeira@yahoo.com>wrote:
>
>> Hi,
>>
>> > What experience does people have to using alternatives to exceptions,
>> > such as option types or exception monads? Does use of third part
>> > libraries that still throws exceptions make such approaches hard to use?
>> > Performance wise it seems to be comparable to catching exceptions or
>> > matching for options, so I guess the difference be might a question of
>> > programming style?
>>
>> Partly yes, though I would say that in Ocaml it is tempting to use
>> exceptions beyond what is reasonable, because they are so cheap and
>> convenient.  As you noted, this can lead to trouble at runtime, which
>> is why some libraries discourage the "exceptional style", preferring
>> option types and forcing users to invoke functions suffixed by "_exc"
>> if they really want to use the exception-based version.
>>
>> Personally, I think the litmus test hinges on whether the supposedly
>> exceptional situation is truly worthy of the name.  If it's a common
>> occurrence, perhaps one should reconsider the use of an "exception".
>> Without meaning to start an holy war, let me just add that even on
>> the Stdlib there are functions (such as Map.S.find) that raise an
>> exception but which should perhaps return an option type.
>>
>> Btw, you didn't mention it explicitly in your message, but I trust you
>> are familiar with "Catch me if you can"? [1]
>>
> I have just read about it, not tested it yet. Do you have any experience
> using this library, especially together with other libraries that also
> provides syntax extension?
>
>
>>
>> Best regards,
>> Dario Teixeira
>>
>> [1]
>> http://dutherenverseauborddelatable.wordpress.com/downloads/exception-monads-for-ocaml/
>>
>>
>>
>>
>> Thanks,
>
> Hans Ole
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

--0016e6d645a885417e04878b1d81
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Jane Street&#39;s Core seems to prefer options to exceptions<br><br><div cl=
ass=3D"gmail_quote">On Wed, May 26, 2010 at 5:10 PM, Hans Ole Rafaelsen <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:hrafaelsen@gmail.com">hrafaelsen@gmail=
.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><br><br><div class=3D"gmail_quote"><div cla=
ss=3D"im">On Wed, May 26, 2010 at 7:30 PM, Dario Teixeira <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:darioteixeira@yahoo.com" target=3D"_blank">darioteix=
eira@yahoo.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-=
left:1px solid rgb(204, 204, 204);padding-left:1ex">
Hi,<br>
<br>
&gt; What experience does people have to using alternatives to exceptions,<=
br>
&gt; such as option types or exception monads? Does use of third part<br>
&gt; libraries that still throws exceptions make such approaches hard to us=
e?<br>
&gt; Performance wise it seems to be comparable to catching exceptions or<b=
r>
&gt; matching for options, so I guess the difference be might a question of=
<br>
&gt; programming style?<br>
<br>
Partly yes, though I would say that in Ocaml it is tempting to use<br>
exceptions beyond what is reasonable, because they are so cheap and<br>
convenient. =A0As you noted, this can lead to trouble at runtime, which<br>
is why some libraries discourage the &quot;exceptional style&quot;, preferr=
ing<br>
option types and forcing users to invoke functions suffixed by &quot;_exc&q=
uot;<br>
if they really want to use the exception-based version.<br>
<br>
Personally, I think the litmus test hinges on whether the supposedly<br>
exceptional situation is truly worthy of the name. =A0If it&#39;s a common<=
br>
occurrence, perhaps one should reconsider the use of an &quot;exception&quo=
t;.<br>
Without meaning to start an holy war, let me just add that even on<br>
the Stdlib there are functions (such as Map.S.find) that raise an<br>
exception but which should perhaps return an option type.<br>
<br>
Btw, you didn&#39;t mention it explicitly in your message, but I trust you<=
br>
are familiar with &quot;Catch me if you can&quot;? [1]<br></blockquote></di=
v><div>I have just read about it, not tested it yet. Do you have any experi=
ence using this library, especially together with other libraries that also=
 provides syntax extension?<br>

=A0</div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1=
ex">
<br>
Best regards,<br>
Dario Teixeira<br>
<br>
[1] <a href=3D"http://dutherenverseauborddelatable.wordpress.com/downloads/=
exception-monads-for-ocaml/" target=3D"_blank">http://dutherenverseaubordde=
latable.wordpress.com/downloads/exception-monads-for-ocaml/</a><br>
<br>
<br>
<br>
<br>
</blockquote></div></div>Thanks,<br><font color=3D"#888888"><br>Hans Ole<br=
>
</font><br>_______________________________________________<br>
Caml-list mailing list. Subscription management:<br>
<a href=3D"http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list" target=
=3D"_blank">http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list</a><br=
>
Archives: <a href=3D"http://caml.inria.fr" target=3D"_blank">http://caml.in=
ria.fr</a><br>
Beginner&#39;s list: <a href=3D"http://groups.yahoo.com/group/ocaml_beginne=
rs" target=3D"_blank">http://groups.yahoo.com/group/ocaml_beginners</a><br>
Bug reports: <a href=3D"http://caml.inria.fr/bin/caml-bugs" target=3D"_blan=
k">http://caml.inria.fr/bin/caml-bugs</a><br>
<br></blockquote></div><br>

--0016e6d645a885417e04878b1d81--


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <florent.ouchet@imag.fr>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by yquem.inria.fr (Postfix) with ESMTP id BD248BC57
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 10:08:38 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ah4FALfF/UuBWB4FgWdsb2JhbACIRYkWjFIBARYiIr9whRME
X-IronPort-AV: E=Sophos;i="4.53,310,1272837600"; 
   d="scan'208";a="51913498"
Received: from mx1.imag.fr (HELO shiva.imag.fr) ([129.88.30.5])
  by mail2-smtp-roc.national.inria.fr with ESMTP; 27 May 2010 10:08:38 +0200
Received: from rhin.imag.fr (rhin.imag.fr [147.171.129.2])
	by shiva.imag.fr (8.13.8/8.13.8) with ESMTP id o4R81VDh018184
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO)
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 10:01:31 +0200
Received: from [147.171.129.114] (prahova.imag.fr [147.171.129.114])
	by rhin.imag.fr (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4R88Xbj022795
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 10:08:34 +0200
Message-ID: <4BFE2881.1070705@imag.fr>
Date: Thu, 27 May 2010 10:08:33 +0200
From: Florent Ouchet <florent.ouchet@imag.fr>
Organization: Tima/CIS
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Static exception analysis or alternative to using
 	exceptions
References: <956439.81564.qm@web111506.mail.gq1.yahoo.com>	<AANLkTimoO4s4ufCPatanWi02vQgNwpUmEAggcdjdcrTf@mail.gmail.com> <AANLkTinyHHP3G3or75nMi2vH5K-8BoBX5cruJ110qqT2@mail.gmail.com>
In-Reply-To: <AANLkTinyHHP3G3or75nMi2vH5K-8BoBX5cruJ110qqT2@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.imag.fr [129.88.30.5]); Thu, 27 May 2010 10:01:31 +0200 (CEST)
X-IMAG-MailScanner-Information: Please contact MI2S MIM  for more information
X-MailScanner-ID: o4R81VDh018184
X-IMAG-MailScanner: Found to be clean
X-IMAG-MailScanner-SpamCheck: 
X-IMAG-MailScanner-From: florent.ouchet@imag.fr
MailScanner-NULL-Check: 1275552095.59286@GauhXa8ftX8zWHCkz1nOUQ
X-Spam: no; 0.00; rafaelsen:01 monads:01 ocaml:01 runtime:01 stdlib:01 syntax:01 beginner's:01 ocaml:01 bug:01 beginner's:01 bug:01 tima:01 26,:98 26,:98 invoke:01 

Hello,

Same here, specially to avoid the Not_found exception.
The optional return values gives the oportunity to have a clear view of 
what is being done if the result is not available.

- Florent

Jacques Le Normand a écrit :
> Jane Street's Core seems to prefer options to exceptions
>
> On Wed, May 26, 2010 at 5:10 PM, Hans Ole Rafaelsen 
> <hrafaelsen@gmail.com <mailto:hrafaelsen@gmail.com>> wrote:
>
>
>
>     On Wed, May 26, 2010 at 7:30 PM, Dario Teixeira
>     <darioteixeira@yahoo.com <mailto:darioteixeira@yahoo.com>> wrote:
>
>         Hi,
>
>         > What experience does people have to using alternatives to
>         exceptions,
>         > such as option types or exception monads? Does use of third part
>         > libraries that still throws exceptions make such approaches
>         hard to use?
>         > Performance wise it seems to be comparable to catching
>         exceptions or
>         > matching for options, so I guess the difference be might a
>         question of
>         > programming style?
>
>         Partly yes, though I would say that in Ocaml it is tempting to use
>         exceptions beyond what is reasonable, because they are so
>         cheap and
>         convenient.  As you noted, this can lead to trouble at
>         runtime, which
>         is why some libraries discourage the "exceptional style",
>         preferring
>         option types and forcing users to invoke functions suffixed by
>         "_exc"
>         if they really want to use the exception-based version.
>
>         Personally, I think the litmus test hinges on whether the
>         supposedly
>         exceptional situation is truly worthy of the name.  If it's a
>         common
>         occurrence, perhaps one should reconsider the use of an
>         "exception".
>         Without meaning to start an holy war, let me just add that even on
>         the Stdlib there are functions (such as Map.S.find) that raise an
>         exception but which should perhaps return an option type.
>
>         Btw, you didn't mention it explicitly in your message, but I
>         trust you
>         are familiar with "Catch me if you can"? [1]
>
>     I have just read about it, not tested it yet. Do you have any
>     experience using this library, especially together with other
>     libraries that also provides syntax extension?
>      
>
>
>         Best regards,
>         Dario Teixeira
>
>         [1]
>         http://dutherenverseauborddelatable.wordpress.com/downloads/exception-monads-for-ocaml/
>
>
>
>
>     Thanks,
>
>     Hans Ole
>
>     _______________________________________________
>     Caml-list mailing list. Subscription management:
>     http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>     Archives: http://caml.inria.fr
>     Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>     Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>   


-- 
Florent Ouchet
PhD Student
CIS/VDS Team - TIMA Laboratory



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <examachine@gmail.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by yquem.inria.fr (Postfix) with ESMTP id 98F18BC57
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 10:50:42 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqgEABfP/UvRVaE0gWdsb2JhbACRW4w1CBUBARYiIq9jggGFTy6ITwEBAwWFDgSDPQ
X-IronPort-AV: E=Sophos;i="4.53,310,1272837600"; 
   d="scan'208";a="51917061"
Received: from mail-fx0-f52.google.com ([209.85.161.52])
  by mail2-smtp-roc.national.inria.fr with ESMTP; 27 May 2010 10:50:42 +0200
Received: by fxm8 with SMTP id 8so3063545fxm.39
        for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 01:50:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:received:in-reply-to
         :references:date:message-id:subject:from:to:cc:content-type;
        bh=k4v4ii25pGX0xQUWxUrTPcr6GQeVrJKvmY0+gPI2BB8=;
        b=DwLBmlF/7tb7Q6SawMKuOMfZ9lHYv7hND6EFlhteJJRNqFiYz5KzFXgBJDTegmw3wD
         yBgVDtRm03hsk+Zl42PspxMsMuyCSHAxghXmVuS7zHxCoaaC/qhDUk2ybNdgylsji4bx
         qu9SxbBoRcYvI9Lup+4Fl+LbS2yCbYq9ul5GA=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=HA1dyTfS4NF/CX5fS0/TjmorMLXERw06+U/Iz6+QFBGdfYbRRTcESDAr+sCkeq2/HV
         GtRyYYtCOBbMbY/YM2dDikhANSqwiQC0/DwafYN3ShgXuXdLjrx2M45+/8EG6KZunWkH
         epW1GpOV1Z/bfTJbw6QAvllJbkv8L9PWCG3Jo=
MIME-Version: 1.0
Received: by 10.223.19.87 with SMTP id z23mr8872109faa.7.1274950241998; Thu, 
	27 May 2010 01:50:41 -0700 (PDT)
Received: by 10.223.115.134 with HTTP; Thu, 27 May 2010 01:50:41 -0700 (PDT)
In-Reply-To: <4BFE2881.1070705@imag.fr>
References: <956439.81564.qm@web111506.mail.gq1.yahoo.com>
	<AANLkTimoO4s4ufCPatanWi02vQgNwpUmEAggcdjdcrTf@mail.gmail.com>
	<AANLkTinyHHP3G3or75nMi2vH5K-8BoBX5cruJ110qqT2@mail.gmail.com>
	<4BFE2881.1070705@imag.fr>
Date: Thu, 27 May 2010 11:50:41 +0300
Message-ID: <AANLkTinV_zrD4SXGnhVSb5C1VZqGhy_1VxGpffvGMnKY@mail.gmail.com>
Subject: Re: [Caml-list] Static exception analysis or alternative to using 
	exceptions
From: Eray Ozkural <examachine@gmail.com>
To: Florent Ouchet <florent.ouchet@imag.fr>
Cc: caml-list@yquem.inria.fr
Content-Type: text/plain; charset=ISO-8859-1
X-Spam: no; 0.00; eray:01 ozkural:01 nesting:01 eray:01 ozkural:01 bilkent:01 wrote:01 exception:01 exception:01 caml-list:01 exceptions:01 imag:02 groups:02 checking:02 static:03 

On Thu, May 27, 2010 at 11:08 AM, Florent Ouchet <florent.ouchet@imag.fr> wrote:
> Hello,
>
> Same here, specially to avoid the Not_found exception.
> The optional return values gives the oportunity to have a clear view of what
> is being done if the result is not available.

That depends on the code, I think. In some cases the exception may
arise from deep in the code, and it would make sense not to bother
with a lot of type overhead for many levels of nesting and function
calling. But if all you are doing is checking the success of a
function, I suppose option types will be more efficient.

Best,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dra-news@metastack.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by yquem.inria.fr (Postfix) with ESMTP id A911CBC57
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 10:54:51 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AskDAEPQ/UtRZ90wkWdsb2JhbACeGBUBAQEBCQsKBxEDH8AxhRME
X-IronPort-AV: E=Sophos;i="4.53,310,1272837600"; 
   d="scan'208";a="51917445"
Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48])
  by mail2-smtp-roc.national.inria.fr with ESMTP; 27 May 2010 10:54:51 +0200
Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35])
          by mtaout02-winn.ispmail.ntl.com
          (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP
          id <20100527085450.PQBW10460.mtaout02-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com>;
          Thu, 27 May 2010 09:54:50 +0100
Received: from romulus.metastack.com ([81.102.132.77])
          by aamtaout04-winn.ispmail.ntl.com
          (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP
          id <20100527085450.BRQP1593.aamtaout04-winn.ispmail.ntl.com@romulus.metastack.com>;
          Thu, 27 May 2010 09:54:50 +0100
Received: from Tenor ([212.183.140.35])
	(authenticated bits=0)
	by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id o4R8sUg3014041
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 27 May 2010 09:54:40 +0100
From: "David Allsopp" <dra-news@metastack.com>
To: "'Florent Ouchet'" <florent.ouchet@imag.fr>,
	<caml-list@yquem.inria.fr>
References: <956439.81564.qm@web111506.mail.gq1.yahoo.com>	<AANLkTimoO4s4ufCPatanWi02vQgNwpUmEAggcdjdcrTf@mail.gmail.com>	<AANLkTinyHHP3G3or75nMi2vH5K-8BoBX5cruJ110qqT2@mail.gmail.com> <4BFE2881.1070705@imag.fr>
In-Reply-To: <4BFE2881.1070705@imag.fr>
Subject: RE: [Caml-list] Static exception analysis or alternative to using	exceptions
Date: Thu, 27 May 2010 09:54:29 +0100
Message-ID: <000c01cafd7a$3f6595e0$be30c1a0$@romulus.metastack.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIBUroxhHU31Hf1sNIRcTuhV5nPKgI6/bv5Ah5T7dsDCni87wHoK2Ms
Content-Language: en-gb
Organization: MetaStack Solutions Ltd.
X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77
X-Cloudmark-Analysis: v=1.1 cv=ZtHxNT4mZm3rCuM0SmWmgWxeBwJsziC8EqOrwwVkrhA= c=1 sm=0 a=TkWsxXdVWLYA:10 a=Lw_SFsgOoS4A:10 a=8sW17jYxVu0A:10 a=kj9zAlcOel0A:10 a=4_0Yma8pdZ_nmy8STiMA:9 a=7G3Op5fPxr4E-5HzM8MA:7 a=W5QCYjlx_W1uCh2dOKaiYSmNDk0A:4 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
X-Spam: no; 0.00; hashtbl:01 wrote:01 exception:01 exception:01 caml-list:01 exceptions:01 static:03 exists:05 exc:07 examples:07 space:07 boxing:08 optional:09 passes:10 analysis:11 

Florent Ouchet wrote:
> Same here, specially to avoid the Not_found exception.
> The optional return values gives the oportunity to have a clear view of
> what is being done if the result is not available.

Agreed - though [find] is one of the examples where you do need find and
find_exc - because often there are occasions where before calling
{Map,Set,Hashtbl}.find you already know that the key exists and so won't
fail at which point the 'a option boxing is a waste of time and space and
Not_found would be a truly exceptional situation so passes the previously
mentioned test.


David 


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mshinwell@janestreet.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by yquem.inria.fr (Postfix) with ESMTP id 0FFC5BC57
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 11:11:17 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAI/T/Usmachw/2dsb2JhbACeGHHAKIUTBIkp
X-IronPort-AV: E=Sophos;i="4.53,310,1272837600"; 
   d="scan'208";a="60118671"
Received: from mx1.janestreet.com ([38.105.200.112])
  by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 May 2010 11:11:16 +0200
Received: from nyc-qsv-mail1.delacy.com ([172.25.22.57])
	by mx1.janestreet.com with esmtp (Exim 4.71)
	(envelope-from <mshinwell@janestreet.com>)
	id 1OHZ7S-0008La-7p
	for caml-list@yquem.inria.fr; Thu, 27 May 2010 05:11:14 -0400
Received: from nyc-qsv-004.delacy.com ([172.25.22.194] helo=qsmtp.delacy.com)
	by nyc-qsv-mail1.delacy.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.71)
	(envelope-from <mshinwell@janestreet.com>)
	id 1OHZ7S-0008P9-Gb; Thu, 27 May 2010 05:11:14 -0400
Received: from ldn-qws-r01.delacy.com ([172.23.65.101] helo=ldn-qws-r01)
	by qsmtp.delacy.com with smtp (Exim 4.71)
	(envelope-from <mshinwell@janestreet.com>)
	id 1OHZ7P-0008KZ-7T; Thu, 27 May 2010 05:11:14 -0400
Received: by ldn-qws-r01 (sSMTP sendmail emulation); Thu, 27 May 2010 10:11:10 +0100
From: "Mark Shinwell" <mshinwell@janestreet.com>
Date: Thu, 27 May 2010 10:11:10 +0100
To: David Allsopp <dra-news@metastack.com>
Cc: 'Florent Ouchet' <florent.ouchet@imag.fr>,
	caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Static exception analysis or alternative to using
	exceptions
Message-ID: <20100527091110.GD18772@janestreet.com>
References: <956439.81564.qm@web111506.mail.gq1.yahoo.com>
 <AANLkTimoO4s4ufCPatanWi02vQgNwpUmEAggcdjdcrTf@mail.gmail.com>
 <AANLkTinyHHP3G3or75nMi2vH5K-8BoBX5cruJ110qqT2@mail.gmail.com>
 <4BFE2881.1070705@imag.fr>
 <000c01cafd7a$3f6595e0$be30c1a0$@romulus.metastack.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000c01cafd7a$3f6595e0$be30c1a0$@romulus.metastack.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam: no; 0.00; shinwell:01 0100,:01 hashtbl:01 popping:01 refactor:01 exn:01 exn:01 variants:01 hacks:01 wrote:01 wrote:01 exception:01 exception:01 assert:01 caml-list:01 

On Thu, May 27, 2010 at 09:54:29AM +0100, David Allsopp wrote:
> Florent Ouchet wrote:
> > Same here, specially to avoid the Not_found exception.
> > The optional return values gives the oportunity to have a clear view of
> > what is being done if the result is not available.
> 
> Agreed - though [find] is one of the examples where you do need find and
> find_exc - because often there are occasions where before calling
> {Map,Set,Hashtbl}.find you already know that the key exists and so won't
> fail at which point the 'a option boxing is a waste of time and space and
> Not_found would be a truly exceptional situation so passes the previously
> mentioned test.

I don't think I agree with this.  I would argue that for the majority of
programs it is likely that the extra overhead is in fact negligible.  In
the cases where it should be impossible to get the None return value, I
think that should probably be annotated as such in the code with "assert
false", which would seem to be more appropriate than a random Not_found
popping up at some much higher level.

In some cases it might be possible to refactor the code to just avoid the
situation entirely, for example by turning this:

  if not (Map.mem my_map key) then
    ..a..
  else
    ..b..
    let data = Map.find_exn my_map key in
    ..c..

into this:

  match Map.find my_map key with
  | None -> ..a..
  | Some data -> ..b.. ..c..

Whilst I agree that there are arguments relating to verbosity of the use
of option types, I think the strongest argument for keeping the *_exn
variants may actually be that they're just a lot more convenient for quick
hacks.

Mark


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <daniel.c.buenzli@gmail.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by yquem.inria.fr (Postfix) with ESMTP id 594AEBC57
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 11:12:20 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiQFAMbU/UvRVdvdemdsb2JhbACDF45zjAYIFQEBFCQDH68hgjqFT4h9AQEDBYEggwRqBI1p
X-IronPort-AV: E=Sophos;i="4.53,310,1272837600"; 
   d="scan'208";a="60118823"
Received: from mail-ew0-f221.google.com ([209.85.219.221])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 27 May 2010 11:12:20 +0200
Received: by ewy21 with SMTP id 21so1404773ewy.7
        for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 02:12:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:sender:received
         :in-reply-to:references:date:x-google-sender-auth:message-id:subject
         :from:to:content-type;
        bh=5LbYUbiMHy9kY2T5VIRO/LiRDdaRP6kIbb2zsYag6Jo=;
        b=Lwj7EC4GNyrYwL8/O7DocRCABZm6tDhAnGqfet9j6cND3fGhRPfCjHwb6KnJ7fOWFZ
         H20VAF5BlWkggPdaoQFlXt7UVMd2jqQhd5H/USGlhEz3msr8DTA/2G6oi4xmbyItPNB/
         l3A86DG6ND+D80ndh3d35QXUa7m8w67eZbTpQ=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=Hccliukv3iIvhuiQPozQ23I0O75iMx9UhyzuMUwghSXexbuAorQalC0oqCzWitsfpL
         xaLE2MrEonAbnXszgYS/Lfe2ABRe9RCbH6/AKfBnq4LkRfWeGEm08PKeyxEO9Wjnf/H4
         78CFIArzd46RupTn1R47SShuVeUsPVb8ekn3c=
MIME-Version: 1.0
Received: by 10.213.29.210 with SMTP id r18mr1939815ebc.20.1274951539436; Thu, 
	27 May 2010 02:12:19 -0700 (PDT)
Sender: daniel.c.buenzli@gmail.com
Received: by 10.213.14.141 with HTTP; Thu, 27 May 2010 02:12:19 -0700 (PDT)
In-Reply-To: <000c01cafd7a$3f6595e0$be30c1a0$@romulus.metastack.com>
References: <956439.81564.qm@web111506.mail.gq1.yahoo.com>
	<AANLkTimoO4s4ufCPatanWi02vQgNwpUmEAggcdjdcrTf@mail.gmail.com>
	<AANLkTinyHHP3G3or75nMi2vH5K-8BoBX5cruJ110qqT2@mail.gmail.com>
	<4BFE2881.1070705@imag.fr>
	<000c01cafd7a$3f6595e0$be30c1a0$@romulus.metastack.com>
Date: Thu, 27 May 2010 11:12:19 +0200
X-Google-Sender-Auth: 4yxzoub7l3IGf6TWR_c8VxcoIgw
Message-ID: <AANLkTinw-Stao4jSM3eVeH2IKH-Um4pAy71xW8X2dTIc@mail.gmail.com>
Subject: Re: [Caml-list] Static exception analysis or alternative to using 
	exceptions
From: =?UTF-8?Q?Daniel_B=C3=BCnzli?= <daniel.buenzli@erratique.ch>
To: caml-list@yquem.inria.fr
Content-Type: text/plain; charset=UTF-8
X-Spam: no; 0.00; buenzli:01 hashtbl:01 exception:01 caml-list:01 exceptions:01 argument:02 static:03 raise:03 daniel:04 daniel:04 exists:05 exc:07 examples:07 space:07 boxing:08 

> Agreed - though [find] is one of the examples where you do need find and
> find_exc - because often there are occasions where before calling
> {Map,Set,Hashtbl}.find you already know that the key exists and so won't
> fail at which point the 'a option boxing is a waste of time and space and
> Not_found would be a truly exceptional situation so passes the previously
> mentioned test.

In that case what you want is an alternate function "really_find" that
doesn't raise Not_found but Invalid_argument if the key cannot be
found.

Best,

Daniel


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <David.Teller@univ-orleans.fr>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by yquem.inria.fr (Postfix) with ESMTP id 045CFBC57
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 11:15:22 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArgFAMbU/UvCpx5XeGdsb2JhbACIRYkWjD0VARUiJMAshRME
X-IronPort-AV: E=Sophos;i="4.53,310,1272837600"; 
   d="scan'208";a="60119160"
Received: from gretchen.univ-orleans.fr ([194.167.30.87])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 27 May 2010 11:15:21 +0200
Received: from localhost (localhost [127.0.0.1])
	by gretchen.univ-orleans.fr (Postfix) with ESMTP id 304053EF66;
	Thu, 27 May 2010 11:15:35 +0200 (CEST)
Received: from gretchen.univ-orleans.fr ([127.0.0.1])
	by localhost (gretchen.univ-orleans.fr [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id BMFMwDVW0n-T; Thu, 27 May 2010 11:15:33 +0200 (CEST)
Received: from smtps.univ-orleans.fr (repartiteur.univ-orleans.fr [194.167.30.199])
	by gretchen.univ-orleans.fr (Postfix) with ESMTP id F35313EB61;
	Thu, 27 May 2010 11:15:32 +0200 (CEST)
Received: from [192.168.1.141] (unknown [213.144.210.93])
	by smtps.univ-orleans.fr (Postfix) with ESMTP id 6983936E60;
	Thu, 27 May 2010 11:15:33 +0200 (CEST)
Subject: Re: [Caml-list] Static exception analysis or alternative to using exceptions
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset=iso-8859-1
From: David Rajchenbach-Teller <David.Teller@univ-orleans.fr>
In-Reply-To: <4BFE2881.1070705@imag.fr>
Date: Thu, 27 May 2010 11:15:18 +0200
Cc: caml-list@yquem.inria.fr
Content-Transfer-Encoding: quoted-printable
Message-Id: <B1041864-558F-4D64-8F4B-B61407752EB0@univ-orleans.fr>
References: <956439.81564.qm@web111506.mail.gq1.yahoo.com>	<AANLkTimoO4s4ufCPatanWi02vQgNwpUmEAggcdjdcrTf@mail.gmail.com> <AANLkTinyHHP3G3or75nMi2vH5K-8BoBX5cruJ110qqT2@mail.gmail.com> <4BFE2881.1070705@imag.fr>
To: Florent Ouchet <florent.ouchet@imag.fr>
X-Mailer: Apple Mail (2.1078)
X-Spam: no; 0.00; univ-orleans:01 type-safe:01 ocaml:01 rafaelsen:01 monads:01 ocaml:01 runtime:01 stdlib:01 syntax:01 beginner's:01 bug:01 beginner's:01 bug:01 tima:01 26,:98 

   Hi,
 If you're interested, three of us on this mailing-list wrote a paper on =
the topic two few years ago [1].

Best regards,
 David

[1] _Catch me if you can Looking for type-safe, hierarchical, =
lightweight, polymorphic and efficient error management in OCaml_, =
http://en.scientificcommons.org/52393896

On May 27, 2010, at 10:08 AM, Florent Ouchet wrote:

> Hello,
>=20
> Same here, specially to avoid the Not_found exception.
> The optional return values gives the oportunity to have a clear view =
of what is being done if the result is not available.
>=20
> - Florent
>=20
> Jacques Le Normand a =E9crit :
>> Jane Street's Core seems to prefer options to exceptions
>>=20
>> On Wed, May 26, 2010 at 5:10 PM, Hans Ole Rafaelsen =
<hrafaelsen@gmail.com <mailto:hrafaelsen@gmail.com>> wrote:
>>=20
>>=20
>>=20
>>    On Wed, May 26, 2010 at 7:30 PM, Dario Teixeira
>>    <darioteixeira@yahoo.com <mailto:darioteixeira@yahoo.com>> wrote:
>>=20
>>        Hi,
>>=20
>>        > What experience does people have to using alternatives to
>>        exceptions,
>>        > such as option types or exception monads? Does use of third =
part
>>        > libraries that still throws exceptions make such approaches
>>        hard to use?
>>        > Performance wise it seems to be comparable to catching
>>        exceptions or
>>        > matching for options, so I guess the difference be might a
>>        question of
>>        > programming style?
>>=20
>>        Partly yes, though I would say that in Ocaml it is tempting to =
use
>>        exceptions beyond what is reasonable, because they are so
>>        cheap and
>>        convenient.  As you noted, this can lead to trouble at
>>        runtime, which
>>        is why some libraries discourage the "exceptional style",
>>        preferring
>>        option types and forcing users to invoke functions suffixed by
>>        "_exc"
>>        if they really want to use the exception-based version.
>>=20
>>        Personally, I think the litmus test hinges on whether the
>>        supposedly
>>        exceptional situation is truly worthy of the name.  If it's a
>>        common
>>        occurrence, perhaps one should reconsider the use of an
>>        "exception".
>>        Without meaning to start an holy war, let me just add that =
even on
>>        the Stdlib there are functions (such as Map.S.find) that raise =
an
>>        exception but which should perhaps return an option type.
>>=20
>>        Btw, you didn't mention it explicitly in your message, but I
>>        trust you
>>        are familiar with "Catch me if you can"? [1]
>>=20
>>    I have just read about it, not tested it yet. Do you have any
>>    experience using this library, especially together with other
>>    libraries that also provides syntax extension?
>>    =20
>>=20
>>        Best regards,
>>        Dario Teixeira
>>=20
>>        [1]
>>        =
http://dutherenverseauborddelatable.wordpress.com/downloads/exception-mona=
ds-for-ocaml/
>>=20
>>=20
>>=20
>>=20
>>    Thanks,
>>=20
>>    Hans Ole
>>=20
>>    _______________________________________________
>>    Caml-list mailing list. Subscription management:
>>    http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>>    Archives: http://caml.inria.fr
>>    Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>    Bug reports: http://caml.inria.fr/bin/caml-bugs
>>=20
>>=20
>> =
------------------------------------------------------------------------
>>=20
>> _______________________________________________
>> Caml-list mailing list. Subscription management:
>> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
>> Archives: http://caml.inria.fr
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>> =20
>=20
>=20
> --=20
> Florent Ouchet
> PhD Student
> CIS/VDS Team - TIMA Laboratory
>=20
>=20
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>=20


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dra-news@metastack.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by yquem.inria.fr (Postfix) with ESMTP id 11564BC57
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 11:19:57 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AskDAOLV/UtRZ90vkWdsb2JhbACDF5sBFQEBAQEJCwoHEQMfryCRCYElgwRqBA
X-IronPort-AV: E=Sophos;i="4.53,310,1272837600"; 
   d="scan'208";a="60119775"
Received: from mtaout01-winn.ispmail.ntl.com ([81.103.221.47])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 27 May 2010 11:19:50 +0200
Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35])
          by mtaout01-winn.ispmail.ntl.com
          (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP
          id <20100527091949.CROO14666.mtaout01-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>;
          Thu, 27 May 2010 10:19:49 +0100
Received: from romulus.metastack.com ([81.102.132.77])
          by aamtaout03-winn.ispmail.ntl.com
          (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP
          id <20100527091949.LDAE1598.aamtaout03-winn.ispmail.ntl.com@romulus.metastack.com>;
          Thu, 27 May 2010 10:19:49 +0100
Received: from Tenor ([212.183.140.35])
	(authenticated bits=0)
	by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id o4R9Jd19014297
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 27 May 2010 10:19:44 +0100
From: "David Allsopp" <dra-news@metastack.com>
To: "=?utf-8?Q?'Daniel_B=C3=BCnzli'?=" <daniel.buenzli@erratique.ch>,
	<caml-list@yquem.inria.fr>
References: <956439.81564.qm@web111506.mail.gq1.yahoo.com>	<AANLkTimoO4s4ufCPatanWi02vQgNwpUmEAggcdjdcrTf@mail.gmail.com>	<AANLkTinyHHP3G3or75nMi2vH5K-8BoBX5cruJ110qqT2@mail.gmail.com>	<4BFE2881.1070705@imag.fr>	<000c01cafd7a$3f6595e0$be30c1a0$@romulus.metastack.com> <AANLkTinw-Stao4jSM3eVeH2IKH-Um4pAy71xW8X2dTIc@mail.gmail.com>
In-Reply-To: <AANLkTinw-Stao4jSM3eVeH2IKH-Um4pAy71xW8X2dTIc@mail.gmail.com>
Subject: RE: [Caml-list] Static exception analysis or alternative to using 	exceptions
Date: Thu, 27 May 2010 10:19:39 +0100
Message-ID: <001501cafd7d$bf138fb0$3d3aaf10$@romulus.metastack.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIBUroxhHU31Hf1sNIRcTuhV5nPKgI6/bv5Ah5T7dsDCni87wHoK2MsAt1+FjADdKdpcg==
Content-Language: en-gb
Organization: MetaStack Solutions Ltd.
X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77
X-Cloudmark-Analysis: v=1.1 cv=ZtHxNT4mZm3rCuM0SmWmgWxeBwJsziC8EqOrwwVkrhA= c=1 sm=0 a=TkWsxXdVWLYA:10 a=VZGMvYHv9TIA:10 a=8sW17jYxVu0A:10 a=IkcTkHD0fZMA:10 a=pGnXrFKX_xHZyv-xBQwA:9 a=tsKVYsz2Ljm7vHSYvgjCBdsWq0wA:4 a=QEXdDO2ut3YA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
X-Spam: no; 0.00; hashtbl:01 wrote:01 naming:01 exception:01 exception:01 caml-list:01 exceptions:01 exceptions:01 argument:02 static:03 library:03 raise:03 daniel:04 exists:05 discussion:06 

Daniel B=C3=BCnzli wrote:
> > Agreed - though [find] is one of the examples where you do need find
> > and find_exc - because often there are occasions where before =
calling
> > {Map,Set,Hashtbl}.find you already know that the key exists and so
> > won't fail at which point the 'a option boxing is a waste of time =
and
> > space and Not_found would be a truly exceptional situation so passes
> > the previously mentioned test.
>=20
> In that case what you want is an alternate function "really_find" that
> doesn't raise Not_found but Invalid_argument if the key cannot be =
found.

Absolutely - but the point is that there is an obvious need to have the =
exception vs 'a option versions of the function. Appropriate naming of =
exceptions in the standard library is a well-rehearsed discussion :o)


David


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dra-news@metastack.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by yquem.inria.fr (Postfix) with ESMTP id A239BBC57
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 11:30:08 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AskDAO/Y/UtRZ90wkWdsb2JhbACeGBUBAQEBCQsKBxEDH8AahRME
X-IronPort-AV: E=Sophos;i="4.53,310,1272837600"; 
   d="scan'208";a="63502914"
Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48])
  by mail4-smtp-sop.national.inria.fr with ESMTP; 27 May 2010 11:29:34 +0200
Received: from aamtaout03-winn.ispmail.ntl.com ([81.103.221.35])
          by mtaout02-winn.ispmail.ntl.com
          (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP
          id <20100527092933.RQFX10460.mtaout02-winn.ispmail.ntl.com@aamtaout03-winn.ispmail.ntl.com>;
          Thu, 27 May 2010 10:29:33 +0100
Received: from romulus.metastack.com ([81.102.132.77])
          by aamtaout03-winn.ispmail.ntl.com
          (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP
          id <20100527092933.LKUG1598.aamtaout03-winn.ispmail.ntl.com@romulus.metastack.com>;
          Thu, 27 May 2010 10:29:33 +0100
Received: from Tenor ([212.183.140.35])
	(authenticated bits=0)
	by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id o4R9TKUr014372
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Thu, 27 May 2010 10:29:25 +0100
From: "David Allsopp" <dra-news@metastack.com>
To: "'Mark Shinwell'" <mshinwell@janestreet.com>,
	"'David Allsopp'" <dra-news@metastack.com>
Cc: "'Florent Ouchet'" <florent.ouchet@imag.fr>,
	<caml-list@yquem.inria.fr>
References: <956439.81564.qm@web111506.mail.gq1.yahoo.com> <AANLkTimoO4s4ufCPatanWi02vQgNwpUmEAggcdjdcrTf@mail.gmail.com> <AANLkTinyHHP3G3or75nMi2vH5K-8BoBX5cruJ110qqT2@mail.gmail.com> <4BFE2881.1070705@imag.fr> <000c01cafd7a$3f6595e0$be30c1a0$@romulus.metastack.com> <20100527091110.GD18772@janestreet.com>
In-Reply-To: <20100527091110.GD18772@janestreet.com>
Subject: RE: [Caml-list] Static exception analysis or alternative to using	exceptions
Date: Thu, 27 May 2010 10:29:20 +0100
Message-ID: <001901cafd7f$19d7afc0$4d870f40$@romulus.metastack.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIBUroxhHU31Hf1sNIRcTuhV5nPKgI6/bv5Ah5T7dsDCni87wHoK2MsAiVzki4BpeZlVg==
Content-Language: en-gb
X-MSL-Actually-To: dra-news@metastack.com
Organization: MetaStack Solutions Ltd.
X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77
X-Cloudmark-Analysis: v=1.1 cv=1ggfb5FlKZQUfF3vzm9UBYZ2uTfLsbs/8dSljwg5+mE= c=1 sm=0 a=TkWsxXdVWLYA:10 a=Lw_SFsgOoS4A:10 a=8sW17jYxVu0A:10 a=kj9zAlcOel0A:10 a=-7hNRWVj5LzQvlpQjmsA:9 a=ZzLzGbLWgODY9-TrAU0A:7 a=YWqmp0EitTGIbwSYez8VWoY1R38A:4 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
X-Spam: no; 0.00; shinwell:01 0100,:01 hashtbl:01 popping:01 compiler:01 exn:01 variants:01 unreadable:01 hashtbl:01 hacks:01 imho:01 wrote:01 wrote:01 exception:01 exception:01 

Mark Shinwell wrote:
> On Thu, May 27, 2010 at 09:54:29AM +0100, David Allsopp wrote:
> > Florent Ouchet wrote:
> > > Same here, specially to avoid the Not_found exception.
> > > The optional return values gives the oportunity to have a clear view
> > > of what is being done if the result is not available.
> >
> > Agreed - though [find] is one of the examples where you do need find
> > and find_exc - because often there are occasions where before calling
> > {Map,Set,Hashtbl}.find you already know that the key exists and so
> > won't fail at which point the 'a option boxing is a waste of time and
> > space and Not_found would be a truly exceptional situation so passes
> > the previously mentioned test.
> 
> I don't think I agree with this.  I would argue that for the majority of
> programs it is likely that the extra overhead is in fact negligible.  In
> the cases where it should be impossible to get the None return value, I
> think that should probably be annotated as such in the code with "assert
> false", which would seem to be more appropriate than a random Not_found
> popping up at some much higher level.

assert false is just a way of renaming the exception and relies on the
rather dirty (but necessary) hack in the compiler that, as a special case,
assert false is not optimised out of a program compiled without debugging
checks.

<snip>

> Whilst I agree that there are arguments relating to verbosity of the use
> of option types, I think the strongest argument for keeping the *_exn
> variants may actually be that they're just a lot more convenient for quick
> hacks.

Unnecessary verbosity = unreadable IMHO, that's one of the reasons we use
clear, functional languages in the first place. That overhead also isn't
negligible as soon as you've got a Hashtbl/Set/Map which is queried a lot
(i.e. just about any form of data processing). Code where you know a priori
that the keys exist becomes unnecessarily peppered with pointless match
clauses (or calls like ExtLib's Option.get which... would raise an exception
if faced with None!). The interest to me is not that the overhead is
negligible, but that it can be trivially removed by using a *better*
function in that instance. Obviously, in the perfect world, your call to the
_exc version would in reality carry a proof that the key will be found (and
so no exception would be necessary). I simply don't see that the overarching
reason to have the _exc version of the function would be simply for hacking
a quick solution to a problem where you can't be bothered to handle the
Not_found case.


David


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alain@frisch.fr>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by yquem.inria.fr (Postfix) with ESMTP id 23EF0BC57
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 11:34:39 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqgEAGbZ/UvB/Bd4dWdsb2JhbACeGBUBFyAFH8AhhRME
X-IronPort-AV: E=Sophos;i="4.53,310,1272837600"; 
   d="scan'208";a="60121741"
Received: from smtp-msa-out01.orange.fr ([193.252.23.120])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 27 May 2010 11:34:38 +0200
Received: from me-wanadoo.net (localhost [127.0.0.1])
	by mwinf5a04.orange.fr (SMTP Server) with ESMTP id 53CF71C00617;
	Thu, 27 May 2010 11:34:38 +0200 (CEST)
Received: from me-wanadoo.net (localhost [127.0.0.1])
	by mwinf5a04.orange.fr (SMTP Server) with ESMTP id 3FA071C00944;
	Thu, 27 May 2010 11:34:38 +0200 (CEST)
Received: from [192.168.1.90] (APuteaux-154-1-15-28.w83-199.abo.wanadoo.fr [83.199.16.28])
	by mwinf5a04.orange.fr (SMTP Server) with ESMTP id E5B591C00617;
	Thu, 27 May 2010 11:34:37 +0200 (CEST)
X-ME-UUID: 20100527093437941.E5B591C00617@mwinf5a04.orange.fr
X-ME-User-Auth: lexifi
Message-ID: <4BFE3CAE.9090107@frisch.fr>
Date: Thu, 27 May 2010 11:34:38 +0200
From: Alain Frisch <alain@frisch.fr>
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: Hans Ole Rafaelsen <hrafaelsen@gmail.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Static exception analysis or alternative to using
 exceptions
References: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com>
In-Reply-To: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam: no; 0.00; frisch:01 frisch:01 rafaelsen:01 monads:01 runtime:01 encapsulated:01 variants:01 exn:01 ocaml:01 polymorphic:01 wrote:01 stack:01 extensible:01 exception:01 exception:01 

On 05/26/2010 06:15 PM, Hans Ole Rafaelsen wrote:
> What experience does people have to using alternatives to exceptions,
> such as option types or exception monads? Does use of third part
> libraries that still throws exceptions make such approaches hard to use?
> Performance wise it seems to be comparable to catching exceptions or
> matching for options, so I guess the difference be might a question of
> programming style?

Indeed, this is mostly a matter of taste and style.

My personal "Rule #1" to decide to use exceptions or not is that one:

  Raising an exception is ok if you know where it will be caught
  or which global effect it will have on the application.


This includes the following cases:

- (Short jumps) Using exceptions locally as shortcuts in loops or more 
complex  algorithms. In that case, the runtime exception is encapsulated 
in a function or module, and should not cause any harm.

- (Long jumps) Using exceptions to report unexpected errors, to which 
the application has little chance to react in a clever way except 
displaying some error messages to the screen or to a log file. The catch 
point is a global exception handler, even though the code raising the 
exception (maybe in a general purpose library) might not know exactly 
how the application will react to the exception.  It is much better if 
the exception describes the problems in terms that can be understood by 
a human (Not_found, even with a stack trace, is not very helpful as an 
error message).

Library function that perform some kind of lookup should return an 
option type and let the caller raise a proper exception to report error 
in a way that makes sense for the application. Similarly for other kind 
of functions that can "fail": use a sum type (or polymorphic variants) 
instead to describe the possible "errors". A variant of the function 
that raises an exception is acceptable for cases where the caller really 
expect the function to succeed (it can fail only because of bugs in the 
application, not because of user or system errors). In that case, 
Assert_failure, or a custom exception, is probably better than 
Not_found. More generally, if exceptions are to be used, custom ones are 
usually better than generic ones (Failure, Invalid_argument).

Another interesting use of exceptions comes from the fact that exn is an 
extensible sum type. (Unfortunately, it is the only one in OCaml.) This 
enables some kinds of loosely typed scenarios, like notification 
messages to be dispatched across global objects in the application: the 
list of possible messages is not fixed in advance, and each object can 
simply use pattern matching to react on messages it is interested in. 
But this is another story...



Alain



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <florent.ouchet@imag.fr>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by yquem.inria.fr (Postfix) with ESMTP id AB6B6BC57
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 13:10:50 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiUEACLw/UuBWB4RgWdsb2JhbACeLwEBFiIiwByFEwQ
X-IronPort-AV: E=Sophos;i="4.53,310,1272837600"; 
   d="scan'208";a="63510003"
Received: from mx2.imag.fr (HELO rominette.imag.fr) ([129.88.30.17])
  by mail4-smtp-sop.national.inria.fr with ESMTP; 27 May 2010 13:10:50 +0200
Received: from rhin.imag.fr (rhin.imag.fr [147.171.129.2])
	by rominette.imag.fr (8.13.8/8.13.8) with ESMTP id o4RB3fNH014933
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Thu, 27 May 2010 13:03:41 +0200
Received: from [147.171.129.114] (prahova.imag.fr [147.171.129.114])
	by rhin.imag.fr (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4RBAjmQ006789;
	Thu, 27 May 2010 13:10:45 +0200
Message-ID: <4BFE5335.9050902@imag.fr>
Date: Thu, 27 May 2010 13:10:45 +0200
From: Florent Ouchet <florent.ouchet@imag.fr>
Reply-To: florent.ouchet@imag.fr
Organization: Tima/CIS
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Eray Ozkural <examachine@gmail.com>
Cc: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Static exception analysis or alternative to using
 	exceptions
References: <956439.81564.qm@web111506.mail.gq1.yahoo.com>	<AANLkTimoO4s4ufCPatanWi02vQgNwpUmEAggcdjdcrTf@mail.gmail.com>	<AANLkTinyHHP3G3or75nMi2vH5K-8BoBX5cruJ110qqT2@mail.gmail.com>	<4BFE2881.1070705@imag.fr> <AANLkTinV_zrD4SXGnhVSb5C1VZqGhy_1VxGpffvGMnKY@mail.gmail.com>
In-Reply-To: <AANLkTinV_zrD4SXGnhVSb5C1VZqGhy_1VxGpffvGMnKY@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (rominette.imag.fr [129.88.30.17]); Thu, 27 May 2010 13:03:41 +0200 (CEST)
X-IMAG-MailScanner-Information: Please contact MI2S MIM  for more information
X-MailScanner-ID: o4RB3fNH014933
X-IMAG-MailScanner: Found to be clean
X-IMAG-MailScanner-SpamCheck: 
X-IMAG-MailScanner-From: florent.ouchet@imag.fr
MailScanner-NULL-Check: 1275563024.38901@e0w8NnKbdM3ret4CUDbXOQ
X-Spam: no; 0.00; redefined:01 compiler:01 syntax:01 ocaml:01 eray:01 ozkural:01 nesting:01 tima:01 assimilable:98 disturbing:98 wrote:01 exception:01 exception:01 symbolic:01 caml-list:01 


In VSYML [1], the exception Not_found was raised deep in the code in 
some functions from List and in some redefined functions (such as 
ocamlutils_find_assoc with a custom key comparer). This project can be 
assimilable to a code compiler or a code interpreter where these 
functions are called during the syntax tree conversion.

There is not "real" problem when the exception is caught at an higher 
level but when the exception is not caught at the "deep-1" level, the 
user will likely receive the wrong error message and this error will 
likely be reported at the wrong position in the VHDL source file. That 
was just disturbing and it required some "tact" to find the exact problem.

In version VSYML 1.7, I switched from exception to optional result and 
the application is more stable. By using optional result, the required 
pattern matching ensures the error handling at the deep-1 level.

[1] VSYML: VHDL Symbolic Simulator in OCaml 
http://users-tima.imag.fr/vds/ouchet/vsyml.html

- Florent

Eray Ozkural a écrit :
> On Thu, May 27, 2010 at 11:08 AM, Florent Ouchet <florent.ouchet@imag.fr> wrote:
>   
>> Hello,
>>
>> Same here, specially to avoid the Not_found exception.
>> The optional return values gives the oportunity to have a clear view of what
>> is being done if the result is not available.
>>     
>
> That depends on the code, I think. In some cases the exception may
> arise from deep in the code, and it would make sense not to bother
> with a lot of type overhead for many levels of nesting and function
> calling. But if all you are doing is checking the success of a
> function, I suppose option types will be more efficient.
>
> Best,
>
>   


-- 
Florent Ouchet
PhD Student
CIS/VDS Team - TIMA Laboratory


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <hcarty@mulethief.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by yquem.inria.fr (Postfix) with ESMTP id E275FBC57
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 15:57:29 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsICABAX/ktKfVM0kWdsb2JhbACDF5p9CBUBAQEBCQsKBxEDH695iDWIX4ElgwRqBA
X-IronPort-AV: E=Sophos;i="4.53,311,1272837600"; 
   d="scan'208";a="63521720"
Received: from mail-gw0-f52.google.com ([74.125.83.52])
  by mail4-smtp-sop.national.inria.fr with ESMTP; 27 May 2010 15:57:24 +0200
Received: by gwj20 with SMTP id 20so4130256gwj.39
        for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 06:57:16 -0700 (PDT)
Received: by 10.150.62.13 with SMTP id k13mr191748yba.133.1274968636198; Thu, 
	27 May 2010 06:57:16 -0700 (PDT)
MIME-Version: 1.0
Sender: hcarty@mulethief.com
Received: by 10.150.177.20 with HTTP; Thu, 27 May 2010 06:56:56 -0700 (PDT)
In-Reply-To: <AANLkTinyHHP3G3or75nMi2vH5K-8BoBX5cruJ110qqT2@mail.gmail.com>
References: <956439.81564.qm@web111506.mail.gq1.yahoo.com> 
	<AANLkTimoO4s4ufCPatanWi02vQgNwpUmEAggcdjdcrTf@mail.gmail.com> 
	<AANLkTinyHHP3G3or75nMi2vH5K-8BoBX5cruJ110qqT2@mail.gmail.com>
From: "Hezekiah M. Carty" <hcarty@atmos.umd.edu>
Date: Thu, 27 May 2010 09:56:56 -0400
X-Google-Sender-Auth: qzFlOh22IFyRi_AjZo9J81pWnSE
Message-ID: <AANLkTilAHguY8LX9ok7pVHnGoCIBZS_ZGMDxd1MX8sG_@mail.gmail.com>
Subject: Re: [Caml-list] Static exception analysis or alternative to using 
	exceptions
To: Jacques Le Normand <rathereasy@gmail.com>
Cc: Hans Ole Rafaelsen <hrafaelsen@gmail.com>,
	caml-list@yquem.inria.fr
Content-Type: text/plain; charset=UTF-8
X-Spam: no; 0.00; 26,:98 wrote:01 exception:01 caml-list:01 functions:01 exceptions:01 exceptions:01 modules:02 seems:03 jacques:03 static:03 wed:06 batteries:91 wrap:08 core:09 

On Wed, May 26, 2010 at 11:37 PM, Jacques Le Normand
<rathereasy@gmail.com> wrote:
> Jane Street's Core seems to prefer options to exceptions
>

Batteries also includes a number of Exceptionless modules (ex.
Array.Exceptionless) which wrap exception-raising functions to use
options instead.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <rich@annexia.org>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by yquem.inria.fr (Postfix) with ESMTP id 65DE7BC57
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 19:01:24 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAGtC/ktQRFuw/2dsb2JhbACeIHHCRYUTBA
X-IronPort-AV: E=Sophos;i="4.53,312,1272837600"; 
   d="scan'208";a="63534037"
Received: from furbychan.cocan.org ([80.68.91.176])
  by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 27 May 2010 19:01:24 +0200
Received: from rich by furbychan.cocan.org with local (Exim 4.63)
	(envelope-from <rich@annexia.org>)
	id 1OHgSQ-0008N4-Mo; Thu, 27 May 2010 18:01:22 +0100
Date: Thu, 27 May 2010 18:01:22 +0100
To: Hans Ole Rafaelsen <hrafaelsen@gmail.com>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Static exception analysis or alternative to using exceptions
Message-ID: <20100527170122.GA28273@annexia.org>
References: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
From: Richard Jones <rich@annexia.org>
X-Spam: no; 0.00; 0200,:01 rafaelsen:01 monads:01 stdlib:01 ocaml:01 lacks:01 impl:01 'open:01 'open:01 26,:98 wrote:01 exception:01 exception:01 caml-list:01 functions:01 

On Wed, May 26, 2010 at 06:15:05PM +0200, Hans Ole Rafaelsen wrote:
> What experience does people have to using alternatives to exceptions, such
> as option types or exception monads? Does use of third part libraries that
> still throws exceptions make such approaches hard to use? Performance wise
> it seems to be comparable to catching exceptions or matching for options, so
> I guess the difference be might a question of programming style?

Personally I've found that you should only throw those exceptions
which can be caught in a single place in the program.  By this I mean
that an exception such as Not_found shouldn't be thrown, and instead
it would be better to use an option type (for stdlib functions which
throw Not_found, you have to be _very_ careful that the exception
cannot "escape").

However if the exception is, say, an I/O error reading a disk file,
these should be thrown, and caught somewhere central where you can
display an error message to the user (for GUI programs) or abort the
current transaction (for server programs).  Recovering from such
exceptions properly is still tricky though.  Since OCaml lacks
'finally', you either have to use a 'finally' impl from a library, or
modify your code to not need it (eg. turning calls to 'open_in' and
'open_out' into a kind of continuation-passing style).  Or for small
programs, abort the program and don't deal with recovery at all.

All in all, this is not ideal for writing correct programs.  Some sort
of exception analysis would be most welcome.

Rich.

-- 
Richard Jones
Red Hat


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <darioteixeira@yahoo.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by yquem.inria.fr (Postfix) with ESMTP id 848CEBC57
	for <caml-list@yquem.inria.fr>; Thu, 27 May 2010 23:13:32 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AisCAP98/ktDww/Hi2dsb2JhbACRZoMyiSEBAQEKCwoHDwUfsRmCAYVaiH0BBAQBhQ4Eg0I
X-IronPort-AV: E=Sophos;i="4.53,313,1272837600"; 
   d="scan'208";a="63542530"
Received: from web111512.mail.gq1.yahoo.com ([67.195.15.199])
  by mail4-smtp-sop.national.inria.fr with SMTP; 27 May 2010 23:13:31 +0200
Received: (qmail 22972 invoked by uid 60001); 27 May 2010 21:13:30 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1274994810; bh=kthBWVELmtlpjsX0hLB6PBJBkD3zzfL54ANqDqWBzBA=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Mtt9Yzn0WnCVgV6tuzMYUNxVvCCzArHSF2kwhR12ySoVNC+7r6cOOJ4jZCBkZJNmUWTOjbHFQg4K0pX0q/x9i4bO7/oss5zoYydM9YBpAFiJBNDchgQUvlrLC3nsEdLRQSSlltMck/M1wyfTGjCtJtZzhVG5EDvRDGQXSAC8tM4=
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=WnLNlACBP3poYbfPtEWtFF/DtY5MPvCnAD7cqB679RPq3MnaAiDWbwoNl6q6oQicvDU1dIFBMzyiL7HMCDDG8R/qSbj30pzZIE5u1VDZ0VnWfif9GCkpG+SdoBBabnMNa5Yp4RD6fu9yQ7oGEqvAby9RV+QZ9+LQMqCf75fSuG0=;
Message-ID: <263033.22957.qm@web111512.mail.gq1.yahoo.com>
X-YMail-OSG: hwR0LGUVM1n62VxHVNI7an6WuHGmLbuM66h4pthBOu7.K6.
 0HaLaOA0xSofxiCdz_vHe84hMDfALjPx8wjIwPe3yqhJZI0mcKSyJtLiF3_h
 OS6EOAlwo4hxVIPDx.K9cDSLTIC2hc78CD1veCKcjmq_NmulMPLaHTXQb7HO
 VC7Gd_bbQbR1opvx2CX3feKaNieY8BdDHflu3LUe55oPZPEwiaj0FqiTfyLG
 Pm7pAzpRx1URQfc8IwuvwHC_XaA3HkyCZxOwiPh9e4yMd7etpmZu3Rej8XyA
 J6moywO7u_RrZ97uVmnQw.rA1J17O1eDTKnWP61w4
Received: from [213.205.71.57] by web111512.mail.gq1.yahoo.com via HTTP; Thu, 27 May 2010 14:13:29 PDT
X-Mailer: YahooMailClassic/11.0.8 YahooMailWebService/0.8.103.269680
Date: Thu, 27 May 2010 14:13:29 -0700 (PDT)
From: Dario Teixeira <darioteixeira@yahoo.com>
Subject: Re: [Caml-list] Static exception analysis or alternative to using exceptions
To: Hans Ole Rafaelsen <hrafaelsen@gmail.com>,
	Richard Jones <rich@annexia.org>
Cc: caml-list@inria.fr
In-Reply-To: <20100527170122.GA28273@annexia.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam: no; 0.00; stdlib:01 invocation:01 cheers:01 exception:01 exception:01 caml-list:01 functions:01 functions:01 exceptions:01 exceptions:01 bears:02 static:03 raise:03 lookup:07 programmer:07 

Hi,=0A=0A> Personally I've found that you should only throw those exception=
s=0A> which can be caught in a single place in the program.=A0 By this I me=
an=0A> that an exception such as Not_found shouldn't be thrown, and instead=
=0A> it would be better to use an option type (for stdlib functions which=
=0A> throw Not_found, you have to be _very_ careful that the exception=0A> =
cannot "escape").=0A=0AYes, I agree.  As an illustration, dictionary lookup=
 functions such as=0AMap.find should return an option type, but use excepti=
ons for truly=0Aexceptional circumstances that no sane programmer should ha=
ve to watch=0Afor at every single invocation (say, "raise Dictionary_eaten_=
by_bears").=0A=0ACheers,=0ADario Teixeira=0A=0A=0A=0A      


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <goswin-v-b@web.de>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by yquem.inria.fr (Postfix) with ESMTP id 5C0C2BBAF
	for <caml-list@yquem.inria.fr>; Mon, 31 May 2010 16:36:24 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmsCAC9mA0zZSMDqkWdsb2JhbACeMxUBAQEBBw0KBxEDH8EVhRYE
X-IronPort-AV: E=Sophos;i="4.53,334,1272837600"; 
   d="scan'208";a="63701168"
Received: from fmmailgate03.web.de ([217.72.192.234])
  by mail4-smtp-sop.national.inria.fr with ESMTP; 31 May 2010 16:36:23 +0200
Received:  from smtp04.web.de  ( [172.20.0.225])
	by fmmailgate03.web.de (Postfix) with ESMTP id 4B166153EDFC1;
	Mon, 31 May 2010 16:36:23 +0200 (CEST)
Received: from [78.43.204.177] (helo=frosties.localdomain)
	by smtp04.web.de with asmtp (TLSv1:AES256-SHA:256)
	(WEB.DE 4.110 #4)
	id 1OJ66J-0001PW-00; Mon, 31 May 2010 16:36:23 +0200
Received: from mrvn by frosties.localdomain with local (Exim 4.71)
	(envelope-from <goswin-v-b@web.de>)
	id 1OJ66I-0000rC-NU; Mon, 31 May 2010 16:36:22 +0200
From: Goswin von Brederlow <goswin-v-b@web.de>
To: Richard Jones <rich@annexia.org>
Cc: Hans Ole Rafaelsen <hrafaelsen@gmail.com>, caml-list@inria.fr
Subject: Re: [Caml-list] Static exception analysis or alternative to using exceptions
References: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com>
	<20100527170122.GA28273@annexia.org>
Date: Mon, 31 May 2010 16:36:22 +0200
In-Reply-To: <20100527170122.GA28273@annexia.org> (Richard Jones's message of
	"Thu, 27 May 2010 18:01:22 +0100")
Message-ID: <87y6f0cf4p.fsf@frosties.localdomain>
User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: goswin-v-b@web.de
X-Sender: goswin-v-b@web.de
X-Provags-ID: V01U2FsdGVkX18zHXw34Y/BRH9Hties74Zz7g9L0a6C8ee4bIaX
	ScXJJS1TdCjtjgHzPC2xccRRTDs2u5lRsriQcbaK1FcDVPpKFU
	KYORbndgg=
X-Spam: no; 0.00; 0200,:01 rafaelsen:01 monads:01 stdlib:01 complicates:01 ocaml:01 lacks:01 impl:01 'open:01 'open:01 val:01 val:01 26,:98 mfg:98 imho:01 

Richard Jones <rich@annexia.org> writes:

> On Wed, May 26, 2010 at 06:15:05PM +0200, Hans Ole Rafaelsen wrote:
>> What experience does people have to using alternatives to exceptions, such
>> as option types or exception monads? Does use of third part libraries that
>> still throws exceptions make such approaches hard to use? Performance wise
>> it seems to be comparable to catching exceptions or matching for options, so
>> I guess the difference be might a question of programming style?
>
> Personally I've found that you should only throw those exceptions
> which can be caught in a single place in the program.  By this I mean
> that an exception such as Not_found shouldn't be thrown, and instead
> it would be better to use an option type (for stdlib functions which
> throw Not_found, you have to be _very_ careful that the exception
> cannot "escape").

Which needlessly complicates your code when it never happens.

Imho a good module should provide both an exception and option based
interface to fit the circumstances and programming style.

> However if the exception is, say, an I/O error reading a disk file,
> these should be thrown, and caught somewhere central where you can
> display an error message to the user (for GUI programs) or abort the
> current transaction (for server programs).  Recovering from such
> exceptions properly is still tricky though.  Since OCaml lacks
> 'finally', you either have to use a 'finally' impl from a library, or
> modify your code to not need it (eg. turning calls to 'open_in' and
> 'open_out' into a kind of continuation-passing style).  Or for small
> programs, abort the program and don't deal with recovery at all.
>
> All in all, this is not ideal for writing correct programs.  Some sort
> of exception analysis would be most welcome.

It would be nice if the possible exceptions of a function would be part
of the type. E.g.

let f1 () = raise Not_found
val f1 : unit -> 'a [ Not_found ]

let f2 () = try f1 () with Not_found -> ()
val f2 : unit -> unit

let f3 f = try f () with Not_found -> ()
val f3: (unit -> 'a [< Not_found | 'B ]) -> 'a [ 'B ]

and so on.


Someone would have to write a new type system for that though.

MfG
        Goswin


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <florent.ouchet@imag.fr>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by yquem.inria.fr (Postfix) with ESMTP id 027A9BBAF
	for <caml-list@yquem.inria.fr>; Mon, 31 May 2010 17:00:36 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AugBAEdsA0yBWB4FmWdsb2JhbACeSAEBAQEBCAsKBxEiwQOFFgQ
X-IronPort-AV: E=Sophos;i="4.53,334,1272837600"; 
   d="scan'208";a="63702886"
Received: from mx1.imag.fr (HELO shiva.imag.fr) ([129.88.30.5])
  by mail4-smtp-sop.national.inria.fr with ESMTP; 31 May 2010 17:00:36 +0200
Received: from rhin.imag.fr (rhin.imag.fr [147.171.129.2])
	by shiva.imag.fr (8.13.8/8.13.8) with ESMTP id o4VErIvU021721
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Mon, 31 May 2010 16:53:18 +0200
Received: from [147.171.129.114] (prahova.imag.fr [147.171.129.114])
	by rhin.imag.fr (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o4VF0VRo014775;
	Mon, 31 May 2010 17:00:33 +0200
Message-ID: <4C03CF0F.9080707@imag.fr>
Date: Mon, 31 May 2010 17:00:31 +0200
From: Florent Ouchet <florent.ouchet@imag.fr>
Reply-To: florent.ouchet@imag.fr
Organization: Tima/CIS
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: Goswin von Brederlow <goswin-v-b@web.de>
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Static exception analysis or alternative to using
 exceptions
References: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com>	<20100527170122.GA28273@annexia.org> <87y6f0cf4p.fsf@frosties.localdomain>
In-Reply-To: <87y6f0cf4p.fsf@frosties.localdomain>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.imag.fr [129.88.30.5]); Mon, 31 May 2010 16:53:18 +0200 (CEST)
X-IMAG-MailScanner-Information: Please contact MI2S MIM  for more information
X-MailScanner-ID: o4VErIvU021721
X-IMAG-MailScanner: Found to be clean
X-IMAG-MailScanner-SpamCheck: 
X-IMAG-MailScanner-From: florent.ouchet@imag.fr
MailScanner-NULL-Check: 1275922400.93456@mrAhhlwugAbJZSUywqai/A
X-Spam: no; 0.00; val:01 val:01 ocamlexc:01 tima:01 discontinued:98 imho:01 compilers:01 exception:01 exception:01 caml-list:01 exceptions:01 exceptions:01 imag:02 module:03 unit:03 

Goswin von Brederlow a écrit :
> Imho a good module should provide both an exception and option based
> interface to fit the circumstances and programming style.
>
>   
+1

> It would be nice if the possible exceptions of a function would be part
> of the type. E.g.
>
> let f1 () = raise Not_found
> val f1 : unit -> 'a [ Not_found ]
>
> let f2 () = try f1 () with Not_found -> ()
> val f2 : unit -> unit
>
> let f3 f = try f () with Not_found -> ()
> val f3: (unit -> 'a [< Not_found | 'B ]) -> 'a [ 'B ]
>
> and so on.
>
>
> Someone would have to write a new type system for that though.
>
>   

ocamlexc gave such results, but this tool is now discontinued and not 
compatible with latest compilers :(

-- 
Florent Ouchet
PhD Student
CIS/VDS Team - TIMA Laboratory



From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dra-news@metastack.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by yquem.inria.fr (Postfix) with ESMTP id A4BA3BBAF
	for <caml-list@yquem.inria.fr>; Mon, 31 May 2010 19:24:33 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmsCAAeOA0xRZ90wkWdsb2JhbACeMxUBAQEBCQsKBxEDH8AghRYE
X-IronPort-AV: E=Sophos;i="4.53,334,1272837600"; 
   d="scan'208";a="52148735"
Received: from mtaout02-winn.ispmail.ntl.com ([81.103.221.48])
  by mail2-smtp-roc.national.inria.fr with ESMTP; 31 May 2010 19:24:33 +0200
Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35])
          by mtaout02-winn.ispmail.ntl.com
          (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP
          id <20100531172431.ZNMB3192.mtaout02-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com>;
          Mon, 31 May 2010 18:24:31 +0100
Received: from romulus.metastack.com ([81.102.132.77])
          by aamtaout02-winn.ispmail.ntl.com
          (InterMail vG.2.02.00.01 201-2161-120-102-20060912) with ESMTP
          id <20100531172431.HYRF1586.aamtaout02-winn.ispmail.ntl.com@romulus.metastack.com>;
          Mon, 31 May 2010 18:24:31 +0100
Received: from Tenor ([172.16.0.8])
	(authenticated bits=0)
	by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id o4VHOQUH012569
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
	Mon, 31 May 2010 18:24:28 +0100
From: "David Allsopp" <dra-news@metastack.com>
To: "'Goswin von Brederlow'" <goswin-v-b@web.de>,
	"'Richard Jones'" <rich@annexia.org>
Cc: <caml-list@inria.fr>
References: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com>	<20100527170122.GA28273@annexia.org> <87y6f0cf4p.fsf@frosties.localdomain>
In-Reply-To: <87y6f0cf4p.fsf@frosties.localdomain>
Subject: RE: [Caml-list] Static exception analysis or alternative to using	exceptions
Date: Mon, 31 May 2010 18:24:28 +0100
Message-ID: <002c01cb00e6$20bfcd30$623f6790$@romulus.metastack.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
thread-index: AQLN/ZnpRZJbIlc1+3otFcfAZdIpzAKcSa79Ajjnp/kBPNfzYw==
Content-Language: en-gb
Organization: MetaStack Solutions Ltd.
X-Scanned-By: MIMEDefang 2.65 on 81.102.132.77
X-Cloudmark-Analysis: v=1.1 cv=1ggfb5FlKZQUfF3vzm9UBYZ2uTfLsbs/8dSljwg5+mE= c=1 sm=0 a=TkWsxXdVWLYA:10 a=Lw_SFsgOoS4A:10 a=8sW17jYxVu0A:10 a=kj9zAlcOel0A:10 a=eyp7H1pdOuFKantkhncA:9 a=PnuJ7GJ05JjBb9enHJisRddJyUgA:4 a=CjuIK1q_8ugA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
X-Spam: no; 0.00; ocaml:01 lacks:01 impl:01 'open:01 'open:01 val:01 val:01 ocamlexc:01 ocaml:01 compiler:01 wrote:01 exception:01 exception:01 caml-list:01 exceptions:01 

Goswin von Brederlow wrote:
<snip>
> > However if the exception is, say, an I/O error reading a disk file,
> > these should be thrown, and caught somewhere central where you can
> > display an error message to the user (for GUI programs) or abort the
> > current transaction (for server programs).  Recovering from such
> > exceptions properly is still tricky though.  Since OCaml lacks
> > 'finally', you either have to use a 'finally' impl from a library, or
> > modify your code to not need it (eg. turning calls to 'open_in' and
> > 'open_out' into a kind of continuation-passing style).  Or for small
> > programs, abort the program and don't deal with recovery at all.
> >
> > All in all, this is not ideal for writing correct programs.  Some sort
> > of exception analysis would be most welcome.
> 
> It would be nice if the possible exceptions of a function would be part of
> the type. E.g.
> 
> let f1 () = raise Not_found
> val f1 : unit -> 'a [ Not_found ]
> 
> let f2 () = try f1 () with Not_found -> () val f2 : unit -> unit
> 
> let f3 f = try f () with Not_found -> () val f3: (unit -> 'a [< Not_found
> | 'B ]) -> 'a [ 'B ]
> 
> and so on.
> 
> 
> Someone would have to write a new type system for that though.

Would it be more practical to have that analysis as part of the .annot file?
Presumably a patch which merged and updated the codebase of ocamlexc to
produce exception-annotations in that manner might have a chance of making
it into the OCaml compiler itself. I'm guessing that what you're getting at
is the ability to see from your code that an exception could escape at any
given point rather than trying to add Java-style "checked exceptions" to
OCaml?


David


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <nicolas.pouillard@gmail.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by yquem.inria.fr (Postfix) with ESMTP id 7DEADBBAF
	for <caml-list@yquem.inria.fr>; Mon, 31 May 2010 21:30:47 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AhECABarA0xKfVI2mGdsb2JhbACeIAgVAQEBAQEICQwHESKvLYIChRsuiE8BAQMFhREEg0g
X-IronPort-AV: E=Sophos;i="4.53,335,1272837600"; 
   d="scan'208";a="60358696"
Received: from mail-ww0-f54.google.com ([74.125.82.54])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 31 May 2010 21:30:47 +0200
Received: by wwb22 with SMTP id 22so461855wwb.27
        for <caml-list@inria.fr>; Mon, 31 May 2010 12:30:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:message-id:date:from:subject
         :to:cc:in-reply-to:references:mime-version:content-type:content-id;
        bh=Dubr9ZxybZvsJJNFV7BgUeuH29LeZGBEvubqpxtExKc=;
        b=htcI74sKXOwCg5f/5RcBQkfwXkw1iG9DdYq+CjXSrS4KGOZ3i/R1mKvwJeODAhONSe
         P8zgwxexxdWgmp/TqaC4rcqTbo7TaFxAxjutIG9doVJn8CGttUKEIefsd0Ud7s2UgLEG
         k3B278rPutDjQBbgIUCk7hKHE8K6edv0qZRFg=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:subject:to:cc:in-reply-to:references
         :mime-version:content-type:content-id;
        b=u0CCVT9Q3XXGJerh4mflx6C9JO3S7uY0XdV5/5+DyXWM8rY6uIWMKKhtkQ5LmqPLuy
         6NCnPXmcBGYrf6MgZCxze1DTbWER6JQiaRhkwdOCELXRiKza24tqt4TAS3WeLrX/DK7F
         HM4IgkdSxwX1vA+gAl8n04aRhfNWCuGq89tRg=
Received: by 10.227.69.141 with SMTP id z13mr4612388wbi.46.1275334247190;
        Mon, 31 May 2010 12:30:47 -0700 (PDT)
Received: from localhost (ks.feydakins.org [91.121.104.209])
        by mx.google.com with ESMTPS id h22sm37389013wbh.21.2010.05.31.12.30.42
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Mon, 31 May 2010 12:30:42 -0700 (PDT)
Message-ID: <4c040e62.9608e30a.4b34.6623@mx.google.com>
Date: Mon, 31 May 2010 12:30:42 -0700 (PDT)
From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
Subject: Re: [Caml-list] Static exception analysis or alternative to using exceptions
To: Goswin von Brederlow <goswin-v-b@web.de>,
	Richard Jones <rich@annexia.org>
Cc: caml-list@inria.fr
In-Reply-To: <87y6f0cf4p.fsf@frosties.localdomain>
References: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com> <20100527170122.GA28273@annexia.org> <87y6f0cf4p.fsf@frosties.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <17516.1275334240.1@ks.feydakins.org>
X-Spam: no; 0.00; 0200,:01 0200,:01 rafaelsen:01 monads:01 stdlib:01 complicates:01 typechecker:01 exn:01 exn:01 26,:98 imho:01 wrote:01 wrote:01 exception:01 exception:01 

On Mon, 31 May 2010 16:36:22 +0200, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> Richard Jones <rich@annexia.org> writes:
> 
> > On Wed, May 26, 2010 at 06:15:05PM +0200, Hans Ole Rafaelsen wrote:
> >> What experience does people have to using alternatives to exceptions, such
> >> as option types or exception monads? Does use of third part libraries that
> >> still throws exceptions make such approaches hard to use? Performance wise
> >> it seems to be comparable to catching exceptions or matching for options, so
> >> I guess the difference be might a question of programming style?
> >
> > Personally I've found that you should only throw those exceptions
> > which can be caught in a single place in the program.  By this I mean
> > that an exception such as Not_found shouldn't be thrown, and instead
> > it would be better to use an option type (for stdlib functions which
> > throw Not_found, you have to be _very_ careful that the exception
> > cannot "escape").
> 
> Which needlessly complicates your code when it never happens.
> 
> Imho a good module should provide both an exception and option based
> interface to fit the circumstances and programming style.

Since having all functions in all flavours can lead to hard to interface
bloat, one should consider tiny functions to switch from a style to another.
It tends to be easier to start from an option type in the case of Not_found
instead of the other way around for the following reason:

  * The typechecker does not remind us to catch the exception.
  * We need a custom handler per exception.
  * We need to take a thunk to delay the computation.

  let not_found_to_option f =
    try Some (f ())
    with Not_found -> None

On the contrary look at:

  let from_option exn = function
    | Some x -> x
    | None -> raise exn

  Example: from_option Not_found (List.find p xs)

Best regards,

-- 
Nicolas Pouillard
http://nicolaspouillard.fr


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <christophe.raffalli@univ-savoie.fr>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by yquem.inria.fr (Postfix) with ESMTP id C5DFEBBAF
	for <caml-list@yquem.inria.fr>; Mon, 31 May 2010 21:36:20 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqECAMyrA0zUGyoFkWdsb2JhbACRci+EUoc1FQEBAQEJCwoHEQMfv0aFFgQ
X-IronPort-AV: E=Sophos;i="4.53,335,1272837600"; 
   d="asc'?scan'208";a="60359033"
Received: from smtp5-g21.free.fr ([212.27.42.5])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 31 May 2010 21:36:19 +0200
Received: from macbookpro.local (bin73-1-78-240-16-62.fbx.proxad.net [78.240.16.62])
	by smtp5-g21.free.fr (Postfix) with ESMTP id A92A2D48174
	for <caml-list@yquem.inria.fr>; Mon, 31 May 2010 21:36:13 +0200 (CEST)
Message-ID: <4C040FA7.6070601@univ-savoie.fr>
Date: Mon, 31 May 2010 21:36:07 +0200
From: Christophe Raffalli <christophe.raffalli@univ-savoie.fr>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4
MIME-Version: 1.0
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Static exception analysis or alternative to using
 exceptions
References: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com>	<20100527170122.GA28273@annexia.org> <87y6f0cf4p.fsf@frosties.localdomain>
In-Reply-To: <87y6f0cf4p.fsf@frosties.localdomain>
X-Enigmail-Version: 1.0.1
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enig5CDC3FB5F3705B43B9E8641D"
X-Spam: no; 0.00; christophe:01 raffalli:01 christophe:01 raffalli:01 univ-savoie:01 val:01 val:01 cheers:01 beginner's:01 ocaml:01 bug:01 mfg:98 polymorphic:01 beginners:01 exception:01 
X-Attachments: type="application/pgp-signature" name="signature.asc" name="signature.asc" 

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5CDC3FB5F3705B43B9E8641D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


> It would be nice if the possible exceptions of a function would be part=

> of the type. E.g.
>
> let f1 () =3D raise Not_found
> val f1 : unit -> 'a [ Not_found ]
>
> let f2 () =3D try f1 () with Not_found -> ()
> val f2 : unit -> unit
>
> let f3 f =3D try f () with Not_found -> ()
> val f3: (unit -> 'a [< Not_found | 'B ]) -> 'a [ 'B ]
>
> and so on.
>  =20
This is what PML does ... and what is nice is that is does not even
require the exception to be garded ...
>
> Someone would have to write a new type system for that though.
>  =20
Yes, but this require very little new technology : a function having one
type or two as return type is basically the same ...
and polymorphic variant are very well suited to be the default practice
for exception (as in your f3 example).

The only questions (I think) are
- complexity of the algorithm (I think it shoud be OK)
- readability of inferred types (one could hide exception types by
default ?)
=20
Cheers,
Christophe

> MfG
>         Goswin
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>  =20



--------------enig5CDC3FB5F3705B43B9E8641D
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwED6wACgkQi9jr/RgYAS7DRgCfV84lEk/FcKShaJsj4TdlEwIk
gakAoLod2i+D+a/rqVWUpV3q22/p4EwB
=LQUm
-----END PGP SIGNATURE-----

--------------enig5CDC3FB5F3705B43B9E8641D--


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <edwintorok@gmail.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83])
	by yquem.inria.fr (Postfix) with ESMTP id D7A4CBBAF
	for <caml-list@yquem.inria.fr>; Mon, 31 May 2010 22:51:50 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuIBAOC9A0zRVaE0mGdsb2JhbACeIggVAQEBAQEICQwHESKvLIIChSAuiE8BAQMFhREEg0M
X-IronPort-AV: E=Sophos;i="4.53,335,1272837600"; 
   d="scan'208";a="52158370"
Received: from mail-fx0-f52.google.com ([209.85.161.52])
  by mail2-smtp-roc.national.inria.fr with ESMTP; 31 May 2010 22:51:50 +0200
Received: by fxm19 with SMTP id 19so2617941fxm.39
        for <caml-list@yquem.inria.fr>; Mon, 31 May 2010 13:51:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:received:received:received:message-id:date:from
         :user-agent:mime-version:to:subject:references:in-reply-to
         :x-enigmail-version:openpgp:content-type:content-transfer-encoding;
        bh=Bdyhyaak8h0ehnjLZP39t00ZaZ8ABZmsY+IFsf0tokQ=;
        b=ZXrsxfmntCP/VWMGhK29a6q/BNn6PDHCzOvtM78RU1kknBmD820yMiDZEPn/8LJYir
         6S/dDm/fYlF+pyxgbFXRJwRW4UK79XiWemfFSkae3jVZBap/HiYgZ5grielIdxORhf9+
         6+f0TZRhDa7G1yAJskVlFMeLTnvyQrt0dGEMI=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:x-enigmail-version:openpgp:content-type
         :content-transfer-encoding;
        b=SnU6SzNRW6NjySD9ZEdBhtx6IY9O6qsCZlg9ztgpyXxSJoAayIyJEyuYv7YRlL56Dx
         ojXzQLD+NUAFwACWaOiI1VHDgnmk6eUA7pvQqjoL7y/IIx8XNF9n6nGglk49dekSeRPN
         cpkTfTp5y3CIYByG2SnRy8N7yQQETvzncoSE8=
Received: by 10.223.54.140 with SMTP id q12mr5944704fag.50.1275339110279;
        Mon, 31 May 2010 13:51:50 -0700 (PDT)
Received: from debian ([79.114.38.162])
        by mx.google.com with ESMTPS id 15sm43384797fad.10.2010.05.31.13.51.48
        (version=TLSv1/SSLv3 cipher=RC4-MD5);
        Mon, 31 May 2010 13:51:48 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by debian (Postfix) with ESMTP id 60C1F15FF32
	for <caml-list@yquem.inria.fr>; Mon, 31 May 2010 23:51:47 +0300 (EEST)
Message-ID: <4C042162.4010103@gmail.com>
Date: Mon, 31 May 2010 23:51:46 +0300
From: =?ISO-8859-1?Q?T=F6r=F6k_Edwin?= <edwintorok@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4
MIME-Version: 1.0
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] Static exception analysis or alternative to using
 exceptions
References: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com>	<20100527170122.GA28273@annexia.org>	<87y6f0cf4p.fsf@frosties.localdomain> <002c01cb00e6$20bfcd30$623f6790$@romulus.metastack.com>
In-Reply-To: <002c01cb00e6$20bfcd30$623f6790$@romulus.metastack.com>
X-Enigmail-Version: 1.0.1
OpenPGP: id=5379965D
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam: no; 0.00; ocaml:01 lacks:01 impl:01 'open:01 'open:01 val:01 val:01 ocamlexc:01 ocaml:01 compiler:01 compile-time:01 bug:01 edwin:98 .....:98 wrote:01 

On 05/31/2010 08:24 PM, David Allsopp wrote:
> Goswin von Brederlow wrote:
> <snip>
>>> However if the exception is, say, an I/O error reading a disk file,
>>> these should be thrown, and caught somewhere central where you can
>>> display an error message to the user (for GUI programs) or abort the
>>> current transaction (for server programs).  Recovering from such
>>> exceptions properly is still tricky though.  Since OCaml lacks
>>> 'finally', you either have to use a 'finally' impl from a library, or
>>> modify your code to not need it (eg. turning calls to 'open_in' and
>>> 'open_out' into a kind of continuation-passing style).  Or for small
>>> programs, abort the program and don't deal with recovery at all.
>>>
>>> All in all, this is not ideal for writing correct programs.  Some sort
>>> of exception analysis would be most welcome.
>>
>> It would be nice if the possible exceptions of a function would be part of
>> the type. E.g.
>>
>> let f1 () = raise Not_found
>> val f1 : unit -> 'a [ Not_found ]
>>
>> let f2 () = try f1 () with Not_found -> () val f2 : unit -> unit
>>
>> let f3 f = try f () with Not_found -> () val f3: (unit -> 'a [< Not_found
>> | 'B ]) -> 'a [ 'B ]
>>
>> and so on.
>>
>>
>> Someone would have to write a new type system for that though.
> 
> Would it be more practical to have that analysis as part of the .annot file?
> Presumably a patch which merged and updated the codebase of ocamlexc to
> produce exception-annotations in that manner might have a chance of making
> it into the OCaml compiler itself. I'm guessing that what you're getting at
> is the ability to see from your code that an exception could escape at any

pattern-match like exhaustive check that all cases are covered could be
useful.
try
...
with Not_found -> ...

error: exception catch clause is not exhaustive, exceptions not covered:
.....

Maybe using a separate keyword, or a compile-time flag for this?

> given point rather than trying to add Java-style "checked exceptions" to
> OCaml?
> 

I think there are 2 things to watch out when looking at Java and exceptions:
 - if a function throws too many exceptions, you sometimes see things
like "throws Exceptions", or "catch (Exception e) { // ignore }" in Java
code, which are completely useless, and might even lead to bugs
(silently ignoring all exceptions)
 - throwing an exception when a lookup doesn't find something is not
always the best. Look at Java's class loader which throws an exception
when a class is not found (pretty common when loading plugins) instead
of returning null.

I think that lookup functions should come in 2 flavours:
 - one that doesn't use exceptions (uses option types), for example
'find'. The key you are looking for may or may not be there
 - one that uses exceptions, for example 'get'. You know that the key is
there (or should be there), and you want the value. If the key isn't
there its probably a bug, or a very rare condition so the exception is
good here. I think the exception variant could even be generated
automatically as a wrapper to the option variant (not viceversa)

Best regards,
--Edwin


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <lukstafi@gmail.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by yquem.inria.fr (Postfix) with ESMTP id AE2F1BBAF
	for <caml-list@yquem.inria.fr>; Mon, 31 May 2010 22:57:44 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuIBAC/AA0zRVaE2mGdsb2JhbACeIggVAQEBAQEICQwHESKvHYIChSAuiE8BAQMFhREE
X-IronPort-AV: E=Sophos;i="4.53,335,1272837600"; 
   d="scan'208";a="60362971"
Received: from mail-fx0-f54.google.com ([209.85.161.54])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 31 May 2010 22:57:44 +0200
Received: by fxm5 with SMTP id 5so2432706fxm.27
        for <caml-list@inria.fr>; Mon, 31 May 2010 13:57:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:received:in-reply-to
         :references:date:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        bh=iZ0YvmpyLk9haMk7mNrOnLjEW8s5cy/3UH3zqMvcqGg=;
        b=t+e7pRhb9SJVWcbSC8C7feuHqUvKCcO8U/2/B8TepEr2Q1bqQtiAGJBui9UIQlXVq5
         BQ8fT5AlegYqPPtUj1C9evWWf5qbqtHAZlGlRhatX3hvuLuDBfjBseTOzQ4PL1U7p9fI
         dJzxjEl2LIwLUyRrTHwyH0JYVvS6U8BurwGj4=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=B5DKyQADUGH/Rq8eUfw4td8uP89JH5vgYxJ1/rPAAMrzY5RsS1sf+eTl3gmxc3KoBq
         pned28hOVZnJLjEyWTa/8f1Kkovkdi2D4DgOYHuhDXhOzbNdEMhjzg/ycTzYCselWN6P
         +0o7iwb5JVvnb2demnIKrxYvI+Y7s7/S5VNfw=
MIME-Version: 1.0
Received: by 10.102.182.28 with SMTP id e28mr2267582muf.78.1275339464147; Mon, 
	31 May 2010 13:57:44 -0700 (PDT)
Received: by 10.204.26.195 with HTTP; Mon, 31 May 2010 13:57:44 -0700 (PDT)
In-Reply-To: <4c040e62.9608e30a.4b34.6623@mx.google.com>
References: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com>
	<20100527170122.GA28273@annexia.org>
	<87y6f0cf4p.fsf@frosties.localdomain>
	<4c040e62.9608e30a.4b34.6623@mx.google.com>
Date: Mon, 31 May 2010 22:57:44 +0200
Message-ID: <AANLkTil7kXzh-dJ6rEohK7OvQuVqz3bc6ToEdmZTbGa2@mail.gmail.com>
Subject: Re: [Caml-list] Static exception analysis or alternative to using 
	exceptions
From: Lukasz Stafiniak <lukstafi@gmail.com>
To: Nicolas Pouillard <nicolas.pouillard@gmail.com>
Cc: caml-list@inria.fr
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Spam: no; 0.00; lukasz:01 typechecker:01 exn:01 exn:01 syntax:01 higher-order:01 iterator:01 callee:01 wrote:01 exception:01 exception:01 caml-list:01 functions:01 functions:01 computation:01 

On Mon, May 31, 2010 at 9:30 PM, Nicolas Pouillard
<nicolas.pouillard@gmail.com> wrote:
>
> Since having all functions in all flavours can lead to hard to interface
> bloat, one should consider tiny functions to switch from a style to anoth=
er.
> It tends to be easier to start from an option type in the case of Not_fou=
nd
> instead of the other way around for the following reason:
>
> =A0* The typechecker does not remind us to catch the exception.
> =A0* We need a custom handler per exception.
> =A0* We need to take a thunk to delay the computation.
>
> =A0let not_found_to_option f =3D
> =A0 =A0try Some (f ())
> =A0 =A0with Not_found -> None
>
> On the contrary look at:
>
> =A0let from_option exn =3D function
> =A0 =A0| Some x -> x
> =A0 =A0| None -> raise exn
>
> =A0Example: from_option Not_found (List.find p xs)
>

I use a syntax extension that catches "Not_found" and raises a failure
instead, with the source location of the "real" offending call. I do
this mostly because OUnit catches exceptions so backtraces are of no
use. When I use the unmodified calls, I always handle Not_found right
away, close to call point -- either by directly catching it, or by
using a higher-order function, like an iterator that expects Not_found
instead of None from the callee. Anyway, I vote for "option"ising all
of the standard library and providing the function "unsome" raising a
string with source code location of its call.


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <bluestorm.dylc@gmail.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by yquem.inria.fr (Postfix) with ESMTP id 8B3D4BBAF
	for <caml-list@yquem.inria.fr>; Mon, 31 May 2010 23:43:02 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuIBAAbKA0xKfVI2mGdsb2JhbACeIggVAQEBAQEICQwHESKvI4IChR0uiE8BAQMFhREE
X-IronPort-AV: E=Sophos;i="4.53,335,1272837600"; 
   d="scan'208";a="63723394"
Received: from mail-ww0-f54.google.com ([74.125.82.54])
  by mail4-smtp-sop.national.inria.fr with ESMTP; 31 May 2010 23:43:01 +0200
Received: by wwb22 with SMTP id 22so540398wwb.27
        for <caml-list@inria.fr>; Mon, 31 May 2010 14:43:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=gamma;
        h=domainkey-signature:mime-version:received:received:in-reply-to
         :references:date:message-id:subject:from:to:cc:content-type;
        bh=uwYsekBr9j4uhUEgopvz6Yknz4JZyMXGvNtsmdci3qE=;
        b=f8dr1o+QHGGRqKJfgP3n+h0zUzlhkj7XGV8K/j648X6N0KU2dzFEsx83ZbQd99aERV
         NwNrEZV6bc210Mn2hPaWa8objW1/iyKNxRpQDzpuNFeKpl2IU1OvO4QW1Qf4ecSKRKjN
         ERUhenRKBCitIw+1HUeGF2rDw6snvH6frjNxw=
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=TKrv0lEzSTPkP0a+6RBi9ecFKAFfRVupqRq8zcpl+WDVJS7DNbBLfbE6WfvG7brMnF
         NMt+b/EPVX/jjb93Cevl9F5XKcFDbRm/nsj0V33QjjO5xgqBAKEG2l7tkOAjun5iw+Ev
         WHNMeVoSUe0xuSCM+5FHx/KEbayetxgDK+Uvk=
MIME-Version: 1.0
Received: by 10.216.87.143 with SMTP id y15mr4687083wee.104.1275342170725; 
	Mon, 31 May 2010 14:42:50 -0700 (PDT)
Received: by 10.216.46.199 with HTTP; Mon, 31 May 2010 14:42:50 -0700 (PDT)
In-Reply-To: <AANLkTil7kXzh-dJ6rEohK7OvQuVqz3bc6ToEdmZTbGa2@mail.gmail.com>
References: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com>
	<20100527170122.GA28273@annexia.org>
	<87y6f0cf4p.fsf@frosties.localdomain>
	<4c040e62.9608e30a.4b34.6623@mx.google.com>
	<AANLkTil7kXzh-dJ6rEohK7OvQuVqz3bc6ToEdmZTbGa2@mail.gmail.com>
Date: Mon, 31 May 2010 23:42:50 +0200
Message-ID: <AANLkTikVbWZYbnyM6mN7Ho8omsA6jjGLACtgJAw7f6ps@mail.gmail.com>
Subject: Re: [Caml-list] Static exception analysis or alternative to using 
	exceptions
From: blue storm <bluestorm.dylc@gmail.com>
To: Lukasz Stafiniak <lukstafi@gmail.com>
Cc: Nicolas Pouillard <nicolas.pouillard@gmail.com>,
	caml-list@inria.fr
Content-Type: text/plain; charset=ISO-8859-1
X-Spam: no; 0.00; syntax:01 backtrace:01 printexc:01 verbose:01 exn:01 printf:01 printf:01 exn:01 printexc:01 backtrace:01 storm:98 exception:01 caml-list:01 exceptions:01 exceptions:01 

> I use a syntax extension that catches "Not_found" and raises a failure
> instead, with the source location of the "real" offending call. I do
> this mostly because OUnit catches exceptions so backtraces are of no
> use.

I have encoutered the same problem and resolved it with explicit
backtrace handling in Printexc. I use the following function wrapper :

let verbose_func func x =
    try func x with exn ->
      Printf.printf "Test error %s\n%!" (Pinrtexc.to_string exn);
      Printf.printf "%s\n%!" (Printexc.get_backtrace ());
      raise exn in


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pronnquist@yahoo.com>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105])
	by yquem.inria.fr (Postfix) with ESMTP id 4D742BBAF
	for <caml-list@yquem.inria.fr>; Tue,  1 Jun 2010 21:08:40 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AnMCADL3BExiiCwlkWdsb2JhbACRfC+MIgEBAQEJCwoHEQMfshWCAoVTiH0BBAQBhREEg0g
X-IronPort-AV: E=Sophos;i="4.53,341,1272837600"; 
   d="scan'208";a="63795986"
Received: from n61.bullet.mail.sp1.yahoo.com ([98.136.44.37])
  by mail4-smtp-sop.national.inria.fr with SMTP; 01 Jun 2010 21:08:39 +0200
Received: from [69.147.84.145] by n61.bullet.mail.sp1.yahoo.com with NNFMP; 01 Jun 2010 19:08:38 -0000
Received: from [98.136.44.161] by t8.bullet.mail.sp1.yahoo.com with NNFMP; 01 Jun 2010 19:08:38 -0000
Received: from [127.0.0.1] by omp602.mail.sp1.yahoo.com with NNFMP; 01 Jun 2010 19:08:38 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 265117.89619.bm@omp602.mail.sp1.yahoo.com
Received: (qmail 27401 invoked by uid 60001); 1 Jun 2010 19:08:38 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1275419318; bh=q9LqSGq6nAHncHSYPQzbK1GNMBiRSxvT6RzgW5JmBDY=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type; b=h9ertOXkmC7J7sG5miw3zBavKCcFPpFjPNdItdAhkw1kPg387GX+pf+lV7r6ZnZsEiZXPGCWzoh4POVmMyVKUDO5HcSGzCJIwICYPfn9UbShbX0r6frwd3gdbdYFWXlGl6nzptRC1x2raqlz321TlAvCf+eICR+csAtfWMF6agE=
DomainKey-Signature:a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type;
  b=G94y1hzu6lfMxScRbJZoINGn7M80aqmp43y2LnOxu1FyrVQTPG1boNfYtuA4OP6VB5o2/dSLYFskVmAdW+VuL7bC8jtVAvQagH7QmITwMnZpVxzFuDcRzWqJXzq56WmYo2hsOIeHSaHYmULdKnne48nRvVThhC7BFBkAzYuJJ/g=;
Message-ID: <983.27376.qm@web45108.mail.sp1.yahoo.com>
X-YMail-OSG: 4lF7k9wVM1l9Wvbo3HyJuLnpSCeYfDp4V5ZZ0y11yQNcsyJ
 iFRrLo3Q6OyuEhlm4cMyPgopaxwa8A6V1sIk5lvdLdFLqHEVGhHKYwfArqNR
 Ue9ecBoLsHIYgJ9cv9vLtA6NlMsXAGZ06pD8ZC3mAJeuBUzQwZ4XSM0sLGyZ
 r9foFMiN9UecpIndiZwS90YJ9wTsrpDTR4q3hRIQvuJDLNhYciNniirtJ1uA
 ORglH1ib.C7xq6nwtbLvWrwQfLpy9kDPz0_vqzzjHO_9RnN57.Sc4PXSpADN
 b30e3Epco1K5xZup0xOEiZoyt7c1FWbq.ASDTqcwd7rK9d0df1476FfxjOm7
 U7dixI33ZCxFgPodwRn0lhaeMxxI3Vxc9HVNI
Received: from [213.65.123.107] by web45108.mail.sp1.yahoo.com via HTTP; Tue, 01 Jun 2010 12:08:37 PDT
X-Mailer: YahooMailRC/374.4 YahooMailWebService/0.8.103.269680
Date: Tue, 1 Jun 2010 12:08:37 -0700 (PDT)
From: Peter Ronnquist <pronnquist@yahoo.com>
Subject: Re: [Caml-list] Static exception analysis or alternative to using exceptions
To: caml-list@inria.fr
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam: no; 0.00; compiler:01 ocaml:01 wrote:01 wrote:01 exception:01 exception:01 caml-list:01 exceptions:01 exceptions:01 static:03 library:03 library:03 inclusion:04 useless:07 batteries:91 


Richard Jones wrote:
"... All in all, this is not ideal for writing correct programs.  Some sort
of exception analysis would be most welcome."

Doesn't the "catch me if you can" library provide this? 

Among the listed features are:
  * case coverage (i.e. the compiler can tell you if you forgot a case or sometimes if you wrote useless ones)

Isn't it so that the "catch me if you can" library solves most (all?) problems related to error handling through exceptions in ocaml?
(The "Batteries included" project has listed it as a possible inclusion
for future versions (http://www.cocan.org/osr/batteriesincluded)

Regards
Peter R



      


From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <goswin-v-b@web.de>
X-Original-To: caml-list@yquem.inria.fr
Delivered-To: caml-list@yquem.inria.fr
Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82])
	by yquem.inria.fr (Postfix) with ESMTP id 1EC60BC57
	for <caml-list@yquem.inria.fr>; Tue,  8 Jun 2010 11:16:25 +0200 (CEST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmkCAC+nDUzZSMDdkWdsb2JhbACeQRUBAQEBCQsKBxEDH70PhRYE
X-IronPort-AV: E=Sophos;i="4.53,383,1272837600"; 
   d="scan'208";a="60857408"
Received: from fmmailgate01.web.de ([217.72.192.221])
  by mail1-smtp-roc.national.inria.fr with ESMTP; 08 Jun 2010 11:16:24 +0200
Received:  from smtp03.web.de  ( [172.20.0.65])
	by fmmailgate01.web.de (Postfix) with ESMTP id 62AAA15DD8F88;
	Tue,  8 Jun 2010 11:16:23 +0200 (CEST)
Received: from [78.43.204.177] (helo=frosties.localdomain)
	by smtp03.web.de with asmtp (TLSv1:AES256-SHA:256)
	(WEB.DE 4.110 #4)
	id 1OLuv1-0000SI-00; Tue, 08 Jun 2010 11:16:23 +0200
Received: from mrvn by frosties.localdomain with local (Exim 4.72)
	(envelope-from <goswin-v-b@web.de>)
	id 1OLuv0-0002IQ-LI; Tue, 08 Jun 2010 11:16:22 +0200
From: Goswin von Brederlow <goswin-v-b@web.de>
To: "David Allsopp" <dra-news@metastack.com>
Cc: "'Goswin von Brederlow'" <goswin-v-b@web.de>,
	"'Richard Jones'" <rich@annexia.org>, <caml-list@inria.fr>
Subject: Re: [Caml-list] Static exception analysis or alternative to using	exceptions
References: <AANLkTimsqfR_SUiytZa_I74_858lm51tbzpCqR1SHCrp@mail.gmail.com>
	<20100527170122.GA28273@annexia.org>
	<87y6f0cf4p.fsf@frosties.localdomain>
	<002c01cb00e6$20bfcd30$623f6790$@romulus.metastack.com>
Date: Tue, 08 Jun 2010 11:16:22 +0200
In-Reply-To: <002c01cb00e6$20bfcd30$623f6790$@romulus.metastack.com> (David
	Allsopp's message of "Mon, 31 May 2010 18:24:28 +0100")
Message-ID: <87aar5995l.fsf@frosties.localdomain>
User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: goswin-v-b@web.de
X-Sender: goswin-v-b@web.de
X-Provags-ID: V01U2FsdGVkX18RX6SAG0Vi6DK2y4SYnE0JZbUMKH1ppcfNxxD+
	GG8C820jEoza0exCvBCJiMAQoCWq5jtAdAQG5owcswtJIeggYq
	t5L2pqU9Y=
X-Spam: no; 0.00; ocaml:01 lacks:01 impl:01 'open:01 'open:01 val:01 val:01 ocamlexc:01 ocaml:01 compiler:01 specifies:01 sig:01 struct:01 hashtbl:01 hashtbl:01 

"David Allsopp" <dra-news@metastack.com> writes:

> Goswin von Brederlow wrote:
> <snip>
>> > However if the exception is, say, an I/O error reading a disk file,
>> > these should be thrown, and caught somewhere central where you can
>> > display an error message to the user (for GUI programs) or abort the
>> > current transaction (for server programs).  Recovering from such
>> > exceptions properly is still tricky though.  Since OCaml lacks
>> > 'finally', you either have to use a 'finally' impl from a library, or
>> > modify your code to not need it (eg. turning calls to 'open_in' and
>> > 'open_out' into a kind of continuation-passing style).  Or for small
>> > programs, abort the program and don't deal with recovery at all.
>> >
>> > All in all, this is not ideal for writing correct programs.  Some sort
>> > of exception analysis would be most welcome.
>> 
>> It would be nice if the possible exceptions of a function would be part of
>> the type. E.g.
>> 
>> let f1 () = raise Not_found
>> val f1 : unit -> 'a [ Not_found ]
>> 
>> let f2 () = try f1 () with Not_found -> () val f2 : unit -> unit
>> 
>> let f3 f = try f () with Not_found -> () val f3: (unit -> 'a [< Not_found
>> | 'B ]) -> 'a [ 'B ]
>> 
>> and so on.
>> 
>> 
>> Someone would have to write a new type system for that though.
>
> Would it be more practical to have that analysis as part of the .annot file?
> Presumably a patch which merged and updated the codebase of ocamlexc to
> produce exception-annotations in that manner might have a chance of making
> it into the OCaml compiler itself. I'm guessing that what you're getting at
> is the ability to see from your code that an exception could escape at any
> given point rather than trying to add Java-style "checked exceptions" to
> OCaml?
>
>
> David

It want it to fail to compile if the interface specifies one set of
exception and the code produces another that is incompatible. The
following should not compile:

module M : sig
  val f : int -> int []
end = struct
  let h = Hashtbl.create 0
  let f x = Hashtbl.find x
end

Since Hashtbl.find can throw Not_found and the function does not catch
that the function still can throw Not_found. This violates the
declaration in the signature that says it never throws an exception.

This goes beyond just annotating what exception can be thrown. It should
do a real validation.

MfG
        Goswin