220 18439 <73f53762-0bb8-4dd6-b273-0d2ee710dfb7@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Thoughts on Exceptions, Expected, and Error Handling Date: Fri, 5 Jun 2015 22:40:41 -0700 (PDT) Lines: 754 Approved: news@gmane.org Message-ID: <73f53762-0bb8-4dd6-b273-0d2ee710dfb7@isocpp.org> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_257_1969512931.1433569241604" X-Trace: ger.gmane.org 1433569258 28836 80.91.229.3 (6 Jun 2015 05:40:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Jun 2015 05:40:58 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBWUPZKVQKGQE642RKIQ@isocpp.org Sat Jun 06 07:40:44 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vn0-f69.google.com ([209.85.216.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z16qZ-0005Wa-Vo for gclcip-std-proposals@m.gmane.org; Sat, 06 Jun 2015 07:40:44 +0200 Original-Received: by vnbg129 with SMTP id g129sf50047474vnb.1 for ; Fri, 05 Jun 2015 22:40:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=jGiUbuVYlFTF5LLw5cUnfQTmPi0iQw5DCL4f93xFGJM=; b=dp1KO8aHeAP0RrG2zcTzTlD1XU+1cUHM/bof3Irfca7VRyTdkRZlZqcySlaFRgJUpl XgkXk7574gBWSJuRbZi/eox+FjGLMiOaAmvOS6UiJNEIoPhsIkSBA0+HrAFPTtAmQ5S7 yQos7UWQifQSARDklqX4hyCRerBqNWQM+2siyPIw9xdPWhEXv9Brpv51lkS8qMduH3al +8nHQyw4p20GCRP+GV53CmC7gMAGxlfo/VasG5fF79zzCNrmtvAhbzVhKG/xS/FufVD+ /ZZyZza/L8CyzK6W2LXY7dpGE5nH5F/ogYA8ASTPXbEBYUuE6hZzJXztAtiJAkmrs9zN Lu1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=jGiUbuVYlFTF5LLw5cUnfQTmPi0iQw5DCL4f93xFGJM=; b=Ih9cjRxZKE2gLeJVnHg3sESGNRVP9o/z61nTUL/AVj1lbzhxJDDIJRlX4mDRNKPXxG NjYHcq4d7p/fd/NvXp4cZlOUKNlt1im02es5dXam4NpBd38G+fAT5H8G3JkyxwA4DXYq ipE6u8YKYZHBSYVjSDVQluZzph+1GMuQpLzF70jH521puIZ1YzusK/lZUOz+iDRlvlzl M00/5d1EFVVMNYRn1zZD4+WDdZoPVbMZuSg1MOEvMUh5jgP0F+UiDkYRelqdCCAuHHxP m8u3j3vDpOU4qnGJBWcSeHb28RxiDbEFMjxSoxXCzWIHfrUv0MhJzWsSYCvsOMC1kvdF z28w== X-Gm-Message-State: ALoCoQmhfcyJZjklCI8ZEiw/Qy707bMWiPiKau5TKIvObQeZc7h8+PSzXc5JJUNsnXHdLYee80hW X-Received: by 10.52.30.129 with SMTP id s1mr8664692vdh.3.1433569243113; Fri, 05 Jun 2015 22:40:43 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.85.106 with SMTP id m97ls1878540qgd.99.gmail; Fri, 05 Jun 2015 22:40:42 -0700 (PDT) X-Received: by 10.140.98.138 with SMTP id o10mr88117qge.33.1433569242494; Fri, 05 Jun 2015 22:40:42 -0700 (PDT) In-Reply-To: <55720C37.3050205@wanadoo.fr> X-Original-Sender: jmckesson@gmail.com 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:18439 Archived-At: ------=_Part_257_1969512931.1433569241604 Content-Type: multipart/alternative; boundary="----=_Part_258_290896459.1433569241604" ------=_Part_258_290896459.1433569241604 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, June 5, 2015 at 4:53:15 PM UTC-4, Vicente J. Botet Escriba wrote= : > > Le 05/06/15 18:36, Nicol Bolas a =C3=A9crit : > =20 > 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 programming= =20 > world" is all well and good... for that world. But that *alone* doesn't= =20 > make it good for C++ or any other world. > =20 > Why do you say that C++ is not a functional language? C++ is=20 > multi-paradigm language, imperative, object oriented, functional, ... > To call something a "functional programming language" requires the=20 inability to break the functional paradigm (admittedly, for varying degrees= =20 of the word "break"). C++ allows you to restrict yourself, to willingly=20 limit yourself to the functional programming box. What people think of when= =20 they say "functional programming language" doesn't give you the choice; you= =20 live within the box or write in some other language. That's why C++ is not a functional language. It permits functional=20 programming, but it doesn't *require* it. > You need to justify this with something more than "this is how things= =20 > work in functional programming monad pattern matching." > =20 > The question is, if expected can be seen as a monad, why don't profit fro= m=20 > all the experience other languages have had with this abstraction. > C++ would only be considered to "profit" from this if you see the addition= =20 of functional elements to the language as a priori good. I do not see the= =20 profit in grafting functional elements into C++. > 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 and= =20 > easily, pass stateful functions to various APIs in C++.=20 > =20 > Labmda expressions are useful by them selves. You have the lambda=20 > calculus. This is the base of the functional programming languages. > Yes, they are. But as I said, C++ doesn't have them *for that reason*. C++= =20 did not add lambda functions to be the basis of a functional programming=20 model. It added them because they were useful to *many uses* of C++,=20 functional or not. So you have to provide a reason to do something beyond "that's how=20 functional programming does it" or "functional languages have something a= =20 lot like that". > You should not try to turn `expected` into full-frontal "functional=20 > programming error handling." Ditch the "monads" and "pattern matching" an= d=20 > so forth; just focus on the basic proposal: a return type that is both=20 > error code and value. > =20 > Why? > When we consider sum types it is normal that we consider pattern matching= ,=20 > them are undissociated. expected is a sum type. And also a monad. And=20 > optional and future and a lot of classes are monads. So why not make use= =20 > the whole set of services that are associated. > .... Because C++ is not a functional programming language. It has no "sum=20 types". It has no "monads". It has no "pattern matching". And it doesn't=20 need any of those. Just because C++ has classes that look like certain functional concepts=20 doesn't mean that C++ ought to treat them the way functional languages=20 treat them. Like I said before, if you want to argue for these things, you= =20 need to do so on C++'s terms, not on the terms of a functional language.=20 There must be some benefit to C++ besides, "that's how functional languages= =20 deal with these." > =20 > and that=E2=80=99s what >> expected would achieve (in contrast to C++03 exception specifications=20 >> which were handled _at runtime_). >> >> The problem with Java checked exceptions is that the syntax simply is= =20 >> not up to the task. >> Every time you call a function, and you don=E2=80=99t want to propagate = the error=20 >> to your caller, >> you have to add a try {}catch{} block. This disrupt the control flow:=20 >> what if you need to do >> something different depending on the success of the call? instead of a= =20 >> simple branch you have >> =20 > to do one thing immediately after the call and another thing in a=20 >> _whole other code block_. >> What if the recovery code is the same among a few calls? you can catch= =20 >> multiple exceptions >> of the same type in the same catch{} block, but then you cannot=20 >> discriminate who raised the exception. >> =20 > > Note that there are folks in this thread suggesting that something like= =20 > this be (eventually) allowed: > > expected.when { > case good (auto value) { use value; } > case failed (auto error) { handle error; } > } > =20 > That looks an awful lot like a catch block. It seems to "disrupt the=20 > control flow" of the program. > =20 > 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 i= t=20 > on the language makes the language more robust. > This "makes the language more robust" only to those who consider the=20 functional programming model to be the one true way of achieving robust=20 code. > It certainly pokes you in the eye a lot. > > It seems to me that not everyone agrees with you that one is particularly= =20 > different from the other. > > Also, with regard to your question of "What if the recovery code is the= =20 > same among a few calls?", `expected` doesn't exactly solve that one eithe= r.=20 > =20 > I don't understand why? > Well, those calls would look something like this: expected v1 =3D stuff(); v1.when{ case good (auto value) { use v1; } case failed (auto error) { handle error; } } //other processing expected v2 =3D stuff2(); v2.when{ case good (auto value) { use v2; } case failed (auto error) { handle error; } } See how both of them use the same "handle error" code? That's what he was= =20 talking about when he said "What if the recovery code is the same among a= =20 few calls?" `expected`, even using this `when` syntax, doesn't improve=20 things compared to the exception case: try{ T v1 =3D stuff(); use v1; } catch(error){ handle error;} //other processing try{ T v2 =3D stuff2(); use v2; } catch(error){ handle error;} Indeed, some might even argue that the exception case is easier to read,=20 since there's no extraneous syntax between the initialization of the `T`=20 values and their use. > Note that expected-style error handling also needs good syntax to be= =20 >> effectively used and not >> incur in the same problems: that=E2=80=99s why I advocate it for C++ onl= y now=20 >> that we=E2=80=99ll have the monadic >> 'do notation' provided by the await 2.0 proposal. >> =20 > > 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 legitimate= =20 > error handling syntax: > > auto b =3D (await (await a).foo()).bar(); > =20 > 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 thi= s=20 > expression."=20 > =20 > You should read again the resumable functions proposal. > *Which* "resumable functions proposal"? The most recent thing on this=20 subject that I can find (N4499) is pure standardese; trying to figure out= =20 what the dozens of changes across dozens of chapters actually means is=20 painful. Even finding out something as simple as what `await` means when=20 applied to an expression is byzantine. If you're talking about N4402, well, that was harder to find, since it's=20 not in the repository=20 . I managed to=20 find it on isocpp.org . I haven't=20 gone through it in any detail, but I haven't seen the part that said=20 `await` means error handling for `expected`. Equally importantly, what I was referring to was the use of the `await`=20 keyword. Which is intended, by both N4402 and N4499, to be used for some=20 form of delaying of processing, so that a task can be resolved. Hence my=20 use of the phrase, "when I *look* at this..." If you have to tell people, "`await` doesn't mean waiting on something to= =20 be finished ," that's= =20 suggests pretty strongly that you're using the wrong tool to get a job done= .. > 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 to= a=20 > must-pass budget appropriations bill. > > That's just disingenuous. > =20 > 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, > That's an admission of hijacking. If something is intended to do X, and=20 then you make it do Y, where Y is decidedly unlike X in more or less every= =20 way, you have *hijacked* that something, turning it into a backdoor to get= =20 Y accomplished. You even admitted this when you said, "I would prefer=20 another name having less asynchronous connotation." If you'd prefer a=20 different name, then clearly that something isn't meant to perform that=20 function. It's things like this that got us our current template metaprogramming=20 functionality. And while there have been good things that came of it, it=20 requires such a degree of expert knowledge that only a minority of C++=20 programmers can use it. Whereas, if it were a designed feature rather than= =20 an ad-hoc hack, it would have been designed to be more useable. --=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/. ------=_Part_258_290896459.1433569241604 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, June 5, 2015 at 4:53:15 PM UTC-4, Vicente J. Bo= tet Escriba wrote:
=20 =20 =20
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 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, ...

To call something a "functional prog= ramming language" requires the inability to break the functional paradigm (= admittedly, for varying degrees of the word "break"). C++ allows you to res= trict yourself, to willingly limit yourself to the functional programming b= ox. What people think of when they say "functional programming language" do= esn't give you the choice; you live within the box or write in some other l= anguage.

That's why C++ is not a functional language. It permits fun= ctional programming, but it doesn't require it.
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.

C++ would only be considered to= "profit" from this if you see the addition of functional elements to the l= anguage as a priori good. I do not see the profit in grafting functional el= ements into C++.
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.

Yes, they are. But as I said, C++ doesn't have them= for that reason. C++ did not add lambda functions to be the basis o= f a functional programming model. It added them because they were useful to= many uses of C++, functional or not.

So you have to provide = a reason to do something beyond "that's how functional programming does it"= or "functional languages have something a lot like that".
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.

... Because C++ is not a functional programming lan= guage. It has no "sum types". It has no "monads". It has no "pattern matchi= ng". And it doesn't need any of those.

Just because C++ has classes = that look like certain functional concepts doesn't mean that C++ ought to t= reat them the way functional languages treat them. Like I said before, if y= ou want to argue for these things, you need to do so on C++'s terms, not on= the terms of a functional language. There must be some benefit to C++ besi= des, "that's how functional languages deal with these."

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:

  expected.when {
    case good (auto value) { use value; = }
    case failed (auto error) { handle error; }
  }

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.

This "makes the language more robust" only to those who c= onsider the functional programming model to be the one true way of achievin= g robust code.
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?

Well, those call= s would look something like this:

expected<T, error_code> v1 =3D stuff();
v1.when{
    case good (auto value) { use v1; }
    case failed (auto error) { handle error; }
  }=

//= other processing

expected<T, error_code<= /span>>= v2 =3D stuff2();
v2.when{
    case good (au= to value) { use v2; }=
 =   ca= se failed = (auto error) { handle error; }  }<= /span>
=

See how both of them use the same "handle error" cod= e? That's what he was talking about when he said "What if the recovery code is the same among a few calls?" `expected`, even using this = `when` syntax, doesn't improve things compared to the exception case:
try= {
T v1 =3D stuff();
use v1;
}
catch(error){ handle error;}

//other processing

try{
T v2 =3D stuff2();use v2;
}
catch(error){ ha= ndle error= ;}

Indeed, some might even argue that the exception = case is easier to read, since there's no extraneous syntax between the init= ialization of the `T` values and their use.
=20
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()).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.

Which "resumable functions proposal"? The most recent th= ing on this subject that I can find (N4499) is pure standardese; trying to = figure out what the dozens of changes across dozens of chapters actually me= ans is painful. Even finding out something as simple as what `await` means = when applied to an expression is byzantine.

If you're talking about = N4402, well, that was harder to find, since it's not in the repository. I man= aged to find it on isocpp= ..org. I haven't gone through it in any detail, but I haven't seen the p= art that said `await` means error handling for `expected`.

Equally i= mportantly, what I was referring to was the use of the `await` keyword. Whi= ch is intended, by both N4402 and N4499, to be used for some form of delayi= ng of processing, so that a task can be resolved. Hence my use of the phras= e, "when I look at this..."

If you have to tell people, "`awa= it` doesn't mean waiting on something to be finished," that's suggests pretty stro= ngly that you're using the wrong tool to get a job done.
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,

That's an admission of hijacking. If something is intended to= do X, and then you make it do Y, where Y is decidedly unlike X in more or = less every way, you have hijacked that something, turning it into a = backdoor to get Y accomplished. You even admitted this when you said, "I would prefer another name having less asynchronous connotation." If you= 'd prefer a different name, then clearly that something isn't meant to perf= orm that function.

It's things like this that got us our current tem= plate metaprogramming functionality. And while there have been good things = that came of it, it requires such a degree of expert knowledge that only a = minority of C++ programmers can use it. Whereas, if it were a designed feat= ure rather than an ad-hoc hack, it would have been designed to be more usea= ble.

--

---
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>.
------=_Part_258_290896459.1433569241604-- ------=_Part_257_1969512931.1433569241604-- .