220 18421 <86769ab5-9309-450e-ba03-fe849e377b67@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 09:36:44 -0700 (PDT) Lines: 366 Approved: news@gmane.org Message-ID: <86769ab5-9309-450e-ba03-fe849e377b67@isocpp.org> References: <1d83a5df-f8b1-41fc-a197-319825b5436d@isocpp.org> <97c9b3aa-44b4-4a63-92a0-a571628b0735@isocpp.org> <1c62b01e-9160-42a2-9ad8-88587a2347e7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_370_2093718160.1433522204730" X-Trace: ger.gmane.org 1433522225 23316 80.91.229.3 (5 Jun 2015 16:37:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jun 2015 16:37:05 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBHNAY6VQKGQE2OHAOPQ@isocpp.org Fri Jun 05 18:37:00 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f198.google.com ([209.85.160.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z0uc0-0003yR-LK for gclcip-std-proposals@m.gmane.org; Fri, 05 Jun 2015 18:36:52 +0200 Original-Received: by ykfr66 with SMTP id r66sf58584185ykf.2 for ; Fri, 05 Jun 2015 09:36:46 -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=cm5NZPeINweuRHLkp1m8hEo66+qoWda7bMmN2uMAGdE=; b=LN9vEiDjY1fzkVfyjAFWCKoE2ju35dno/ovqhbA2HKbBtKMwzywcR2G/3xYmMS3emh OatzuFlGMw8yJpHIKoX8nq6mOu+NM/v5kiUS34iHBkAjgI0TeAlN8r33HYxPM3oKam3t UtAHyntMWRTRWpVyHZEhevdXjRRlGWG+B3kLlzC+vqT2Y0SrgrvDxoO7/aiGKuxDiSYB 4uZjyaUdy5Ph+oS1L5H1NkAOdaCBx1KqJ94xVSefswLVMFh9Yn2OXII5cOE8P24Oh9rm QnfpUVBkj6yTP6qcr28EnuaNBHhaT8w6OTYCIXHK2T9Zb0CFfDd4mJdBiro2pTp6y4mi ay2Q== 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=cm5NZPeINweuRHLkp1m8hEo66+qoWda7bMmN2uMAGdE=; b=IVuoxeonIdZjXYokcMscokxcedK9a88hmpZcP0dreO2z6rn3FC4SM0sHSd1O6QPBun QvddjEkS9rv+Uxl+mIi4OcWQX32CnjDPIN7G7xhBye9NZq54ZQ6AaoiPs1zKvn1yKJcT AbHzID2hp6JlscvuDc1+FFW0kk5HtpgH/8eCEXdWhaVsU2A8Gub9TJzYQPxHaJKN1k8a EIG25N0nWCQUGNN5NO+gnLEprfKwh/rYQFytO6CccGu2NksBXrFIa6z4auNQPxziDfTK stBgcysDTa0Xbm0kQodOGDuW+Y0sE6DnAa4hxfhFPWky2Xm8tcFIWkhMca6eLq/Yn9ZX /OLw== X-Gm-Message-State: ALoCoQmJdL3RbqrykjeM3Gd87a7ih6W88+e/Fc8FV2Ecobz4UhOAEDSt0JF4hlHP2fm2Kj5PQLC7 X-Received: by 10.52.168.130 with SMTP id zw2mr4958043vdb.5.1433522206394; Fri, 05 Jun 2015 09:36:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.38.177 with SMTP id t46ls1697087qgt.14.gmail; Fri, 05 Jun 2015 09:36:45 -0700 (PDT) X-Received: by 10.140.101.22 with SMTP id t22mr53453qge.32.1433522205619; Fri, 05 Jun 2015 09:36:45 -0700 (PDT) In-Reply-To: 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:18421 Archived-At: ------=_Part_370_2093718160.1433522204730 Content-Type: multipart/alternative; boundary="----=_Part_371_1635480255.1433522204737" ------=_Part_371_1635480255.1433522204737 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Friday, June 5, 2015 at 8:34:24 AM UTC-4, Nicola Gigante wrote: > > Il giorno 05/giu/2015, alle ore 11:35, R=C3=B3bert D=C3=A1vid > ha scritto: > > > 2015. j=C3=BAnius 4., cs=C3=BCt=C3=B6rt=C3=B6k 0:41:24 UTC+2 id=C5=91pont= ban Nicol Bolas a=20 > k=C3=B6vetkez=C5=91t =C3=ADrta: >> >> Yeah, Java tried that with `throw` specifications. It is fairly widely= =20 >> agreed that this approach *sucked*. >> > > Why? I mean, Google/Bing/insert_your_favorite_search_engine_here gives=20 > results, but very few of them go beyond "it sucks", and those that do, th= ey=20 > are inconsistent, and mostly rant on the *implementation*, not the *idea*= .. > > In C++03 standardese it sucked because of a design issue that resulted in= =20 > a big performance hit: all functions having to catch(...) and call=20 > std::terminate if encountered a non-listed exception. It was "less" probl= em=20 > for some compilers because they chose to ignore it (making them essential= ly=20 > non-standard) apart from the empty specification, making essentially=20 > throw() =3D=3D noexcept v0.9. > > > The main problem of Java exception specifications is not exception=20 > specifications themselves, imho. > The problem is that exceptions are the default and only error mechanism= =20 > used in the Java world > (besides returning null objects), and the syntax is not convenient enough= =20 > for this heavy usage. > > In my opinion it is good to use the type system to _force_ the caller to= =20 > handle the error > (even if just to explicitly ignore it). > That=E2=80=99s the best practice in the strongly typed functional program= ming=20 > world, > I'm sure it is. So what? C++ is not a functional language, nor is it going to become one in the near= =20 future. What happens in "the strongly typed functional programming world"= =20 is all well and good... for that world. But that *alone* doesn't make it=20 good for C++ or any other world. You need to justify this with something more than "this is how things work= =20 in functional programming monad pattern matching." 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++. Similarly, we=20 shouldn't have `expected` because it's how error handling is done "in=20 functional programming". We should have it because it offers up a very=20 useful option for handling errors locally in C++, solving a number of=20 problems associated with returning error codes. You should not try to turn `expected` into full-frontal "functional=20 programming error handling." Ditch the "monads" and "pattern matching" and= =20 so forth; just focus on the basic proposal: a return type that is both=20 error code and value. 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 not= =20 > up to the task. > Every time you call a function, and you don=E2=80=99t want to propagate t= he error=20 > to your caller, > you have to add a try {}catch{} block. This disrupt the control flow: wha= t=20 > if you need to do > something different depending on the success of the call? instead of a=20 > simple branch you have > to do one thing immediately after the call and another thing in a _whole=20 > 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. > 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; } } That looks an awful lot like a catch block. It seems to "disrupt the=20 control flow" of the program. 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 either.= =20 If you have two functions that return two `expected` objects, you still=20 have to test each one in turn. Also, if the recovery code "is the same among a few calls", you don't *need= *=20 to discriminate between them. Not unless they're using different values=20 that are specific to each call. And even that is solved by simply=20 extracting the identical code into a function, that gets called with the=20 parameters it needs. And again, `expected` doesn't solve that either. If the code uses different= =20 values that are specific to each error's cause, you still need to extract= =20 the code into functions and use parameters on them. 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++ only= now that=20 > 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= =20 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(); 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 this= =20 expression." Using the former for the *sole purpose* of achieving the=20 latter is a brutal language hack, not good syntax. If you want to have syntax for dealing with `expected` more easily, then=20 propose that. But don't hijack a perfectly good coroutine proposal just to= =20 graft `expected`-based error handling onto it. Make it a separate=20 construct, rather than some kind of Congressional rider amendment that's=20 attached to a must-pass budget appropriations bill. That's just disingenuous. --=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_371_1635480255.1433522204737 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, June 5, 2015 at 8:34:24 AM UTC-4, Nicola Gigant= e wrote:
Il giorno 05/giu/2015, al= le ore 11:35, R=C3=B3bert D=C3=A1vid <lrd...@gmail.com> ha scritto:


2015. j=C3=BAnius 4., cs=C3=BCt=C3=B6rt=C3=B6k 0:41:24 UTC= +2 id=C5=91pontban Nicol Bolas a k=C3=B6vetkez=C5=91t =C3=ADrta:
Yeah, Java tried that wi= th `throw` specifications. It is fairly widely agreed that this approach sucked.

Why? I mean, Google/Bing/inse= rt_your_favorite_search_engine_here gives results, but very few of the= m go beyond "it sucks", and those that do, they are inconsistent, and mostl= y rant on the *implementation*, not the *idea*.

In C++03 standardese= it sucked because of a design issue that resulted in a big performance hit= : all functions having to catch(...) and call std::terminate if encountered= a non-listed exception. It was "less" problem for some compilers because t= hey chose to ignore it (making them essentially non-standard) apart from th= e empty specification, making essentially throw() =3D=3D noexcept v0.9.
=

The main problem of = Java exception specifications is not exception specifications themselves, i= mho.
The problem is that exceptions are the default and only erro= r mechanism used in the Java world
(besides returning null object= s), and the syntax is not convenient enough for this heavy usage.

In my opinion it is good to use the type system to _force_ = the caller to handle the error
(even if just to explicitly ignore= it).
That=E2=80=99s the best practice in the strongly typed func= tional programming world,

I'm sure i= t is.

So what?

C++ is not a functional language, nor is it go= ing to become one in the near future. What happens in "the strongly typed f= unctional programming world" is all well and good... for that world. But th= at alone doesn't make it good for C++ or any other world.

You= need to justify this with something more than "this is how things work in = functional programming monad pattern matching."

We don't have lambda= expressions because they're useful "in functional programming"; we have th= em because it's useful to be able to, quickly and easily, pass stateful fun= ctions to various APIs in C++. Similarly, we shouldn't have `expected` beca= use 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 local= ly in C++, solving a number of problems associated with returning error cod= es.

You should not try to turn `expected` into full-frontal "functio= nal 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.

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

The probl= em 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 propagate the error to your caller,
you have to add a try {}ca= tch{} block. This disrupt the control flow: what if you need to do
something different depending on the success of the call? instead of a si= mple branch you have
to do on= e 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 c= atch{} block, but then you cannot discriminate who raised the exception.

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

  expected<= /span>.when {
    case good (auto value) {= use value; }
    case failed (auto err= or)= { handle error; }
  }

That looks an aw= ful lot like a catch block. It seems to "disrupt the control flow" of the p= rogram.

It certainly pokes you in the eye a lot.

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

Also, with regard to your question of "What if the reco= very code is the same among a few calls?", `expected` doesn't exactly solve= that one either. If you have two functions that return two `expected` obje= cts, you still have to test each one in turn.

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 co= de into a function, that gets called with the parameters it needs.

A= nd 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 t= he code into functions and use parameters on them.

=
Note that expected-style error handling also nee= ds good syntax to be effectively used and not
incur in the same p= roblems: that=E2=80=99s why I advocate it for C++ only now that we=E2=80=99= ll have the monadic
'do notation' provided by the await 2.0 propo= sal.

What "await 2.0 proposal" are y= ou referring to? What 'do notation'? I don't see anything like this in N449= 9.

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

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

When I look at this, I= see syntax that says "stop here until this completes", not syntax that say= s, "handle errors that are returned by this expression." Using the former f= or the sole purpose of achieving the latter is a brutal language hac= k, not good syntax.

If you want to have syntax for dealing with `exp= ected` more easily, then propose that. But don't hijack a perfectly good co= routine proposal just to graft `expected`-based error handling onto it. Mak= e it a separate construct, rather than some kind of Congressional rider ame= ndment that's attached to a must-pass budget appropriations bill.

Th= at's just disingenuous.

--

---
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_371_1635480255.1433522204737-- ------=_Part_370_2093718160.1433522204730-- .