220 18431 <55720C37.3050205@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: Fri, 05 Jun 2015 22:53:11 +0200 Lines: 591 Approved: news@gmane.org Message-ID: <55720C37.3050205@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------020707000507090809080600" X-Trace: ger.gmane.org 1433537614 10469 80.91.229.3 (5 Jun 2015 20:53:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jun 2015 20:53:34 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBOMYZCVQKGQEBCTVE6A@isocpp.org Fri Jun 05 22:53:25 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-la0-f71.google.com ([209.85.215.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z0yc6-0000RU-TA for gclcip-std-proposals@m.gmane.org; Fri, 05 Jun 2015 22:53:14 +0200 Original-Received: by laboh3 with SMTP id oh3sf22535161lab.0 for ; Fri, 05 Jun 2015 13:53:14 -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:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=+qRperIeAks6xUpprqpW9holAGaC5vA12Tv3RWazisk=; b=UPVqOLWKCQCY8H0KRdvppqjpHi/1tycIJ9sDZ2qvYIdkZYDIuhg+MQg3O1rf2VbpeI sx4JzJR6SNlfSRaP75wZl/y7texhzRjxB9qmiUn2Zxf0S7TWtopCX2Wy6zZwJk/qDQj/ iUfIYimy51bdeuLlGxBbZzeq1c9MKezCO+jHpR8Nit3yalzdosEl6QTh5v8TmQS7YvW/ om7N9FsxHI/MMYLtVyDLsvAZ/lCdO2VG9rfDvZORhjqdE8rjTLpbRQSna50u4kx2F0On r6tzEVwB+IDwEVsK34lPgVzTjn7CTUaN339J0fGb3GjzY8mWG+WpxoPSNHBF5Q31TwCJ Ue5g== X-Gm-Message-State: ALoCoQm6x9fbmsobyPh0EzFTyMI2l7JsUxjRZieUVPIwM/bwq6Dxxclg/JoGgIo7x2cDf7nwPkqy X-Received: by 10.152.87.140 with SMTP id ay12mr4749705lab.1.1433537594479; Fri, 05 Jun 2015 13:53:14 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.82.4 with SMTP id e4ls496001wiy.39.gmail; Fri, 05 Jun 2015 13:53:12 -0700 (PDT) X-Received: by 10.194.174.194 with SMTP id bu2mr9887286wjc.76.1433537592859; Fri, 05 Jun 2015 13:53:12 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp05.smtpout.orange.fr. [80.12.242.127]) by mx.google.com with ESMTPS id fh9si6093389wib.20.2015.06.05.13.53.12 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 05 Jun 2015 13:53:12 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.127 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.127; Original-Received: from new-host.home ([2.11.252.224]) by mwinf5d09 with ME id cktB1q0044rF3xu03ktBoY; Fri, 05 Jun 2015 22:53:12 +0200 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Fri, 05 Jun 2015 22:53:12 +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: <86769ab5-9309-450e-ba03-fe849e377b67@isocpp.org> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.127 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-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:18431 Archived-At: This is a multi-part message in MIME format. --------------020707000507090809080600 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 05/06/15 18:36, Nicol Bolas a =C3=A9crit : > On Friday, June 5, 2015 at 8:34:24 AM UTC-4, Nicola Gigante wrote: > > C++ is not a functional language, nor is it going to become one in the=20 > near future. What happens in "the strongly typed functional=20 > programming world" is all well and good... for that world. But that=20 > /alone/ doesn't make it good for C++ or any other world. Why do you say that C++ is not a functional language? C++ is=20 multi-paradigm language, imperative, object oriented, functional, ... > > You need to justify this with something more than "this is how things=20 > work in functional programming monad pattern matching." The question is, if expected can be seen as a monad, why don't profit=20 from all the experience other languages have had with this abstraction.=20 Just because C++ has already exceptions is not a good reason for me,=20 because the use cases expected try to cover in C++ is when the user=20 don't want exceptions. > > We don't have lambda expressions because they're useful "in functional=20 > programming"; we have them because it's useful to be able to, quickly=20 > and easily, pass stateful functions to various APIs in C++. Labmda expressions are useful by them selves. You have the lambda=20 calculus. This is the base of the functional programming languages. C++=20 lambdas are based on this mathematical model that has been there for=20 decades. C++ Lambdas have just been adapted to the C++ world. > Similarly, we shouldn't have `expected` because it's how error=20 > handling is done "in functional programming". We should have it=20 > because it offers up a very useful option for handling errors locally=20 > in C++, solving a number of problems associated with returning error=20 > codes. Agreed. > > You should not try to turn `expected` into full-frontal "functional=20 > programming error handling." Ditch the "monads" and "pattern matching"=20 > and so forth; just focus on the basic proposal: a return type that is=20 > both error code and value. Why? When we consider sum types it is normal that we consider pattern=20 matching, them are undissociated. expected is a sum type. And also a=20 monad. And optional and future and a lot of classes are monads. So why=20 not make use the whole set of services that are associated. > > and that=E2=80=99s what > expected would achieve (in contrast to C++03 exception > specifications which were handled _at runtime_). > > The problem with Java checked exceptions is that the syntax simply > is not up to the task. > Every time you call a function, and you don=E2=80=99t want to propaga= te > the error to your caller, > you have to add a try {}catch{} block. This disrupt the control > flow: what if you need to do > something different depending on the success of the call? instead > of a simple branch you have > > to do one thing immediately after the call and another thing in a > _whole other code block_. > What if the recovery code is the same among a few calls? you can > catch multiple exceptions > of the same type in the same catch{} block, but then you cannot > discriminate who raised the exception. > > > Note that there are folks in this thread suggesting that something=20 > like this be (eventually) allowed: > > | > expected.when{ > casegood (autovalue){usevalue;} > casefailed (autoerror){handle error;} > } > | > > That looks an awful lot like a catch block. It seems to "disrupt the=20 > control flow" of the program. This is just pattern matching. Even if there is not yet a concrete=20 proposal for pattern matching, I see it as unavoidable. Of course this=20 pattern matching would be adapted to the C++ world. There are already a lot of libraries that have a match function. Having=20 it on the language makes the language more robust. > > It certainly pokes you in the eye a lot. > > It seems to me that not everyone agrees with you that one is=20 > particularly different from the other. > > Also, with regard to your question of "What if the recovery code is=20 > the same among a few calls?", `expected` doesn't exactly solve that=20 > one either. I don't understand why? > If you have two functions that return two `expected` objects, you=20 > still have to test each one in turn. Note that pattern patching is not reserved to only one value. We have=20 also non-member functions like fmap that are adapted to this case. > > Also, if the recovery code "is the same among a few calls", you don't=20 > /need/ to discriminate between them. Not unless they're using=20 > different values that are specific to each call. And even that is=20 > solved by simply extracting the identical code into a function, that=20 > gets called with the parameters it needs. > > And again, `expected` doesn't solve that either. If the code uses=20 > different values that are specific to each error's cause, you still=20 > need to extract the code into functions and use parameters on them. Having when() or pattern matching doesn't implies that you can not build=20 other abstraction on top of them. A concrete example would help to show =20 this can be done. > > Note that expected-style error handling also needs good syntax to > be effectively used and not > incur in the same problems: that=E2=80=99s why I advocate it for C++ = only > now that we=E2=80=99ll have the monadic > 'do notation' provided by the await 2.0 proposal. > > > What "await 2.0 proposal" are you referring to? What 'do notation'? I=20 > don't see anything like this in N4499. > > Also, something will seriously be wrong in C++ if this becomes=20 > legitimate error handling syntax: > > | > autob =3D(await (await a).foo()).bar(); > | > > When I look at this, I see syntax that says "stop here until this=20 > completes", not syntax that says, "handle errors that are returned by=20 > this expression." You should read again the resumable functions proposal. You are wrong.=20 The await operator has two roles; sequence the execution of the=20 continuation when the expression is ready and propagate the error if any=20 without executing the continuation. Usually for futures there is an=20 execution agent that would make the future ready. expected as optional=20 are always ready, so the continuation will be executed only if there is=20 no error. This is the magic. Even if monadic interface are not as transparent as exception based=20 interface, they allow to make almost transparent the error propagation. > Using the former for the /sole purpose/ of achieving the latter is a=20 > brutal language hack, not good syntax. Any syntax can be abused and the distinction often this is a style=20 question, but you know that already. > > If you want to have syntax for dealing with `expected` more easily,=20 > then propose that. There is no need to propose anything else if await proposal works. I=20 would prefer another name having less asynchronous connotation. but=20 awaiting something that is already ready just works. In the original=20 Expected proposal I used the 'expect' keyword, 'try' could work as well=20 as 'do'. > But don't hijack a perfectly good coroutine proposal just to graft=20 > `expected`-based error handling onto it. Make it a separate construct,=20 > rather than some kind of Congressional rider amendment that's attached=20 > to a must-pass budget appropriations bill. > > That's just disingenuous. There is no hijacking at all. The features is defined as it is, and it=20 allows this kind of usage. I could concede that the original proposed=20 feature was not intended to managed these cases, but when the feature=20 was generalized to other types other than future, what was proposed was=20 some kind of do-notation adapted to the C++ language. You can believe it=20 or not, this is a fact. 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/. --------------020707000507090809080600 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 05/06/15 18:36, Nicol Bolas a =C3=A9crit=C2=A0:
On Friday, June 5, 2015 at 8:34:24 AM UTC-4, Nicola Gigante wrote:

C++ is not a functional language, nor is it going to become one in the near future. What happens in "the strongly typed functional programming world" is all well and good... for that world. But that alone doesn't make it good for C++ or any other world.
Why do you say that C++ is not a functional language? C++ is multi-paradigm language, imperative, object oriented, functional, ...

You need to justify this with something more than "this is how things work in functional programming monad pattern matching."
The question is, if expected can be seen as a monad, why don't profit from all the experience other languages have had with this abstraction. Just because C++ has already exceptions is not a good reason for me, because the use cases expected try to cover in C++ is when the user don't want exceptions.

We don't have lambda expressions because they're useful "in functional programming"; we have them because it's useful to be able to, quickly and easily, pass stateful functions to various APIs in C++.
Labmda expressions are useful by them selves. You have the lambda calculus. This is the base of the functional programming languages. C++ lambdas are based on this mathematical model that has been there for decades. C++ Lambdas have just been adapted to the C++ world.
Similarly, we shouldn't have `expected` because it's how error handling is done "in functional programming". We should have it because it offers up a very useful option for handling errors locally in C++, solving a number of problems associated with returning error codes.
Agreed.

You should not try to turn `expected` into full-frontal "functional programming error handling." Ditch the "monads" and "pattern matching" and so forth; just focus on the basic proposal: a return type that is both error code and value.
Why?
When we consider sum types it is normal that we consider pattern matching, them are undissociated. expected is a sum type. And also a monad. And optional and future and a lot of classes are monads. So why not make use the whole set of services that are associated.

and that=E2=80=99s what
expected would achieve (in contrast to C++03 exception specifications which were handled _at runtime_).

The problem with Java checked exceptions is that the syntax simply is not up to the task.
Every time you call a function, and you don=E2=80=99t wa= nt to propagate the error to your caller,
you have to add a try {}catch{} block. This disrupt the control flow: what if you need to do
something different depending on the success of the call? instead of a simple branch you have
to do one thing immediately after the call and another thing in a _whole other code block_.
What if the recovery code is the same among a few calls? you can catch multiple exceptions
of the same type in the same catch{} block, but then you cannot discriminate who raised the exception.

Note that there are folks in this thread suggesting that something like this be (eventually) allowed:

=C2=A0 expected.when<= /span> {
=C2=A0 =C2=A0 case good (auto valu= e) { use valu= e; }
=C2=A0 =C2=A0 case failed (auto erro= r) { handle error; }
=C2=A0 }

That looks an awful lot like a catch block. It seems to "disrupt the control flow" of the program.
This is just pattern matching. Even if there is not yet a concrete proposal for pattern matching, I see it as unavoidable. Of course this pattern matching would be adapted to the C++ world.
There are already a lot of libraries that have a match function. Having it on the language makes the language more robust.

It certainly pokes you in the eye a lot.

It seems to me that not everyone agrees with you that one is particularly different from the other.

Also, with regard to your question of "What if the recovery code is the same among a few calls?", `expected` doesn't exactly solve that one either.
I don't understand why?

If you have two functions that return two `expected` objects, you still have to test each one in turn.
Note that pattern patching is not reserved to only one value. We have also non-member functions like fmap that are adapted to this case.

Also, if the recovery code "is the same among a few calls", you don't need to discriminate between them. Not unless they're using different values that are specific to each call. And even that is solved by simply extracting the identical code into a function, that gets called with the parameters it needs.

And again, `expected` doesn't solve that either. If the code uses different values that are specific to each error's cause, you still need to extract the code into functions and use parameters on them.
Having when() or pattern matching doesn't implies that you can not build other abstraction on top of them. A concrete example would help to show=C2=A0 this can be done.

Note that expected-style error handling also needs good syntax to be effectively used and not
incur in the same problems: that=E2=80=99s why I advocat= e it for C++ only now that we=E2=80=99ll have the monadic
'do notation' provided by the await 2.0 proposal.

What "await 2.0 proposal" are you referring to? What 'do notation'? I don't see anything like this in N4499.

Also, something will seriously be wrong in C++ if this becomes legitimate error handling syntax:

auto b =3D (await (await a).foo()).<= /span>bar();

When I look at this, I see syntax that says "stop here until this completes", not syntax that says, "handle errors that are returned by this expression."
You should read again the resumable functions proposal. You are wrong. The await operator has two roles; sequence the execution of the continuation when the expression is ready and propagate the error if any without executing the continuation. Usually for futures there is an execution agent that would make the future ready. expected as optional are always ready, so the continuation will be executed only if there is no error. This is the magic.
Even if monadic interface are not as transparent as exception based interface, they allow to make almost transparent the error propagation.
Using the former for the sole purpose of achieving the latter is a brutal language hack, not good syntax.
Any syntax can be abused and the distinction often this is a style question, but you know that already.

If you want to have syntax for dealing with `expected` more easily, then propose that.
There is no need to propose anything else if await proposal works. I would prefer another name having less asynchronous connotation. but awaiting something that is already ready just works. In the original Expected proposal I used the 'expect' keyword, 'try' could work as well as 'do'.
But don't hijack a perfectly good coroutine proposal just to graft `expected`-based error handling onto it. Make it a separate construct, rather than some kind of Congressional rider amendment that's attached to a must-pass budget appropriations bill.

That's just disingenuous.
There is no hijacking at all. The features is defined as it is, and it allows this kind of usage. I could concede that the original proposed feature was not intended to managed these cases, but when the feature was generalized to other types other than future, what was proposed was some kind of do-notation adapted to the C++ language. You can believe it or not, this is a fact.

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>.
--------------020707000507090809080600-- .