From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 1D3CD7EEBF for ; Tue, 7 Jul 2015 07:40:22 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of outlook_3d217a1f0df94dbd@outlook.com) identity=pra; client-ip=65.54.190.22; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mlin@mlin.net"; x-sender="outlook_3d217a1f0df94dbd@outlook.com"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of mlin@mlin.net) identity=mailfrom; client-ip=65.54.190.22; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mlin@mlin.net"; x-sender="mlin@mlin.net"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@BAY004-OMC1S11.hotmail.com) identity=helo; client-ip=65.54.190.22; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="mlin@mlin.net"; x-sender="postmaster@BAY004-OMC1S11.hotmail.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0B0AQCMZZtVlRa+NkFcgkWBIWABhHCqDZBUAQuFO4ICTAEBAQEBARIBAQEBBw0JCR8whDx4DgGBHjWIDA2jP4QFAaJdAQoBAQEBHY42hE8MQR2BFAWMVIdEhGKEY4NzlwoXghscgVNvAQSCRgEBAQ X-IPAS-Result: A0B0AQCMZZtVlRa+NkFcgkWBIWABhHCqDZBUAQuFO4ICTAEBAQEBARIBAQEBBw0JCR8whDx4DgGBHjWIDA2jP4QFAaJdAQoBAQEBHY42hE8MQR2BFAWMVIdEhGKEY4NzlwoXghscgVNvAQSCRgEBAQ X-IronPort-AV: E=Sophos;i="5.15,420,1432591200"; d="scan'208,217";a="139175868" Received: from bay004-omc1s11.hotmail.com ([65.54.190.22]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES256-SHA; 07 Jul 2015 07:40:20 +0200 Received: from BAY176-W30 ([65.54.190.59]) by BAY004-OMC1S11.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 6 Jul 2015 22:40:18 -0700 X-TMN: [OWbDO0p9eRt3arQqBJGYmFh9Jw2pG0yP] X-Originating-Email: [mlin@mlin.net] Message-ID: Content-Type: multipart/alternative; boundary="_85f87f0b-fdb1-4de5-858f-1356a7d11e0a_" From: Mike Lin Sender: To: "caml-list@inria.fr" Date: Tue, 7 Jul 2015 05:40:18 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Jul 2015 05:40:18.0615 (UTC) FILETIME=[686A2470:01D0B877] X-Validation-by: mlin@mlin.net Subject: [Caml-list] Lwt and exceptions (2015) --_85f87f0b-fdb1-4de5-858f-1356a7d11e0a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, I've long been observing the admonishment to avoid raising native exception= s in Lwt code [1,2]. However, it has not escaped my notice that between Lwt= .catch, the try%lwt syntax extension, and the fact that Lwt.bind sets up a = handler for native exceptions raised in asynchronous callbacks [3], they're= usually handled just as one would naively expect. Actually, I spent a litt= le time trying to come up with a non-terribly-contrived example where using= a native exception breaks the intended handling logic, and did not succeed= ... Perhaps the situation has evolved over time as some of the aforementioned f= eatures have been added to Lwt. Can anyone venture to define precisely when= it's wrong to raise native exceptions in Lwt code, as of 2015? [1] https://mirage.io/wiki/tutorial-lwt[2] http://caml-list.inria.narkive.c= om/YRIVPWeD/lwt-and-exceptions[3] https://github.com/ocsigen/lwt/blob/bb75e= 9185e2cf9a71d13b5008d08dae8fdc90f4d/src/core/lwt.ml#L653 Mike =20=09=09=20=09=20=20=20=09=09=20=20= --_85f87f0b-fdb1-4de5-858f-1356a7d11e0a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear all,

I've long been observing the admonishment to avoid raising native e= xceptions in Lwt code [1,2]. However, it has not escaped my notice that bet= ween Lwt.catch, the try%lwt syntax extension, and the fact that Lwt.bind se= ts up a handler for native exceptions raised in asynchronous callbacks [3],= they're usually handled just as one would naively expect. Actually, I spen= t a little time trying to come up with a non-terribly-contrived example whe= re using a native exception breaks the intended handling logic, and did not= succeed...

Perhaps the situation has evolved over= time as some of the aforementioned features have been added to Lwt. Can an= yone venture to define precisely when it's wrong to raise native exceptions= in Lwt code, as of 2015?

[1] https://mirage.io/wi= ki/tutorial-lwt
[2] http://caml-list.inria.narkive.com/YRIVPWeD/l= wt-and-exceptions
[3] https://github.com/ocsigen/lwt/blob/bb75e91= 85e2cf9a71d13b5008d08dae8fdc90f4d/src/core/lwt.ml#L653

=
Mike

= --_85f87f0b-fdb1-4de5-858f-1356a7d11e0a_--