220 18540 <557760F6.3050909@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Thoughts on Exceptions, Expected, and Error Handling Date: Tue, 09 Jun 2015 23:56:06 +0200 Lines: 260 Approved: news@gmane.org Message-ID: <557760F6.3050909@wanadoo.fr> References: <1d83a5df-f8b1-41fc-a197-319825b5436d@isocpp.org> <97c9b3aa-44b4-4a63-92a0-a571628b0735@isocpp.org> <1c62b01e-9160-42a2-9ad8-88587a2347e7@isocpp.org> <86769ab5-9309-450e-ba03-fe849e377b67@isocpp.org> <55720C37.3050205@wanadoo.fr> <73f53762-0bb8-4dd6-b273-0d2ee710dfb7@isocpp.org> <44339266-A822-41F5-9A02-C402CB31877E@gmail.com> <33bf1010-4067-402a-a025-b1ed10d15707@isocpp.org> <9F17DB76-2423-4048-84CD-A4A28742BFDD@gmail.com> <18a21440-69ab-427e-999a-c8f263ff0488@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000309060600010905010007" X-Trace: ger.gmane.org 1433886984 5191 80.91.229.3 (9 Jun 2015 21:56:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Jun 2015 21:56:24 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBB6GB3WVQKGQENKATFPY@isocpp.org Tue Jun 09 23:56:10 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f199.google.com ([209.85.217.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z2RVC-0001XD-1M for gclcip-std-proposals@m.gmane.org; Tue, 09 Jun 2015 23:56:10 +0200 Original-Received: by lbbqq2 with SMTP id qq2sf7746010lbb.0 for ; Tue, 09 Jun 2015 14:56:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=/nVdJ+ZtsKEomGqg8H4+ydOGmzTkvGiZRKVmzoLLQDA=; b=RkElGbTE/83p9IkbDY0n561lb6L9RpQyTqNEeWgMQiu1f/lc8jOaPfY+HS++yjOcbq PHYepN7rWgbkrIpU8fI9eOgp+W2SZ1/3du7hjmPHL56lCN/skmUNis/9xs5+5P3mFZMi Yb+0Tc20oZNVvjcEYdcG49IXb6TUSBUZsmoiMqmjnZSpbGsJwZ+3VOoWQvY4E+y3QThD +TVcqm4TuQC7a8dsJtEntfVIphn80Ed6jidwoGT/KbGZX2yR4wwztDL1NBHvFkE/le4w DC57rtLRvH1PA80QPU0tmJJulxBmTcg1JFM3mSUgZp/dvJpGMoFOcqVX47heWOjhz9o4 VH7g= X-Gm-Message-State: ALoCoQkx80H00uOanNmCt6a6CbQKS89hmKrYfGsdTwZE+jlyDxou46XRNrT8KQIEDfi2Kgfv4F6A X-Received: by 10.152.219.166 with SMTP id pp6mr1507599lac.1.1433886969546; Tue, 09 Jun 2015 14:56:09 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.126.3 with SMTP id mu3ls1285982wib.45.canary; Tue, 09 Jun 2015 14:56:08 -0700 (PDT) X-Received: by 10.194.109.167 with SMTP id ht7mr45126670wjb.60.1433886968408; Tue, 09 Jun 2015 14:56:08 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr. [80.12.242.123]) by mx.google.com with ESMTPS id fw6si13755107wjc.63.2015.06.09.14.56.08 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jun 2015 14:56:08 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.123 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.123; Original-Received: from new-host.home ([2.11.252.224]) by mwinf5d01 with ME id eMw71q0024rF3xu03Mw7ZF; Tue, 09 Jun 2015 23:56:08 +0200 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Tue, 09 Jun 2015 23:56:08 +0200 X-ME-IP: 2.11.252.224 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <18a21440-69ab-427e-999a-c8f263ff0488@isocpp.org> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.123 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mail=vicente.botet@wanadoo.fr Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:18540 Archived-At: This is a multi-part message in MIME format. --------------000309060600010905010007 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 09/06/15 17:36, Giovanni Piero Deretta a =C3=A9crit : > On Sunday, June 7, 2015 at 2:23:50 PM UTC+1, Nicola Gigante wrote: > > [...] > > Again, high level that means that the following code: > > expected func2(); > expected func() { > T v =3D await func2(); > > yield v * 2; > } > > is roughly equivalent to: > > expected func2(); > expected func() { > expected e =3D func2(); > > return e.then([](T v) { > return v * 2; > }); > } > > > Cool. Christopher Kohlhoff and Oliver Kowalke proposed a coroutine=20 > variant which would infer await, so the example would become (IIRC): > > expected func2(); > expected func() { > T v =3D func2(); > > return v * 2; > } > > also expected is such a fundamental concept that we might want to add=20 > language support for it, something like: > > T func2() expected(E); > T func() expected(E) { > T v =3D func2(); > yield v*2; > } > > Of course syntatic sugar for calling catch_error might also be useful: > > T func2() expected(E); > T func() expected(E) { > do_try { > T v =3D func2(); > yield v*2; > } catch_error(E e) > { > // log e > raise e; > } > } > > What, that reminds me of something.... > > With enough syntatic sugar, exceptions and expected are semantically=20 > equivalent, with the notable difference that the expected error type=20 > is statically checked (but then again you can have except=20 > ). The biggest difference is in the preferred implementation: an=20 > explicit CSP transformation with yield/await and non local jumps for=20 > exceptions, but either feature could be implemented with either strategy. > > I do like 'expected' and the fact that the coroutine proposals work as=20 > monadic do notation is great, but given the history behind C++ we are=20 > probably better of with: > > * an attribute to ask the compiler to make different trade-off between=20 > the normal and exceptional case. > * the addition of optional static exception checking which would close=20 > the last gap between exceptions and expected. Static exceptions types=20 > are considered a failure in Java, but I believe that parametric=20 > exception specifications and possibly inference a-la 'throw(auto)'=20 > would remove most of the complains of exception specifications. And=20 > anyway expected is really equivalent to them. > Thanks Giovanni for describing so clearly the similarities and the=20 differences. The syntax splitting the return type and the error is awesome, even if=20 what is behind is a return type with either a T or an E. The removal of await would satisfy more than one. Vicente --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --------------000309060600010905010007 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 09/06/15 17:36, Giovanni Piero Deretta a =C3=A9crit=C2=A0:
On Sunday, June 7, 2015 at 2:23:50 PM UTC+1, Nicola Gigante wrote:
[...]

Again, high level that means that the following code:

expected<T,E> func2();
expected<T,E> func() {
=C2=A0 =C2=A0T v =3D await func2();

=C2=A0 =C2=A0yield v * 2;
}

is roughly equivalent to:

expected<T,E> func2();
expected<T,E> func() {
=C2=A0 =C2=A0expected<T,E> e =3D func2();

=C2=A0 =C2=A0return e.then([](T v) {
=C2=A0 =C2=A0 =C2=A0return v * 2;
=C2=A0 =C2=A0});
}


Cool. Christopher Kohlhoff and Oliver Kowalke proposed a coroutine variant which would infer await, so the example would become (IIRC):
=C2=A0
expected<T,E> func2();
expected<T,E> func() {
=C2=A0 =C2=A0T v =3D func2();

=C2=A0 return v * 2;
}

also expected is such a fundamental concept that we might want to add language support for it, something like:

T func2() expected(E);
T func() expected(E) {
=C2=A0=C2=A0=C2=A0 T v =3D func2();
=C2=A0=C2=A0=C2=A0 yield v*2;
}

Of course syntatic sugar for calling catch_error=C2=A0 might also be useful:

T func2() expected(E);
T func() expected(E) {
=C2=A0=C2=A0 do_try {
=C2=A0 =C2=A0 =C2=A0 T v =3D func2();
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yield v*2;
=C2=A0=C2=A0 } catch_error(E e)
=C2=A0 {
=C2=A0=C2=A0=C2=A0 // log e
=C2=A0=C2=A0=C2=A0 raise e;
=C2=A0}
}

What, that reminds me of something....

With enough syntatic sugar, exceptions and expected are semantically equivalent, with the notable difference that the expected error type is statically checked (but then again you can have except<T, std::any> ). The biggest difference is in the preferred implementation: an explicit CSP transformation with yield/await and non local jumps for exceptions, but either feature could be implemented with either strategy.

I do like 'expected' and the fact that the coroutine proposals work as monadic do notation is great, but given the history behind C++ we are probably better of with:

* an attribute to ask the compiler to make different trade-off between the normal and exceptional case.
* the addition of optional static exception checking which would close the last gap between exceptions and expected. Static exceptions types are considered a failure in Java, but I believe that parametric exception specifications and possibly inference a-la 'throw(auto)' would remove most of the complains of exception specifications. And anyway expected is really equivalent to them.

Thanks Giovanni for describing so clearly the similarities and the differences.
The syntax splitting the return type and the error is awesome, even if what is behind is a return type with either a T or an E.
The removal of await would satisfy more than one.

Vicente

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--------------000309060600010905010007-- .