220 18446 <0243bdcb-c0a1-4343-88d6-caef3e962cbb@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Thoughts on Exceptions, Expected, and Error Handling Date: Sat, 6 Jun 2015 00:24:31 -0700 (PDT) Lines: 383 Approved: news@gmane.org Message-ID: <0243bdcb-c0a1-4343-88d6-caef3e962cbb@isocpp.org> References: <1d83a5df-f8b1-41fc-a197-319825b5436d@isocpp.org> <97c9b3aa-44b4-4a63-92a0-a571628b0735@isocpp.org> <303e5cc6-8a3e-4063-880e-eac448ec0dc6@isocpp.org> <55729C6A.7020707@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_314_1281707761.1433575471831" X-Trace: ger.gmane.org 1433575484 25500 80.91.229.3 (6 Jun 2015 07:24:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Jun 2015 07:24:44 +0000 (UTC) Cc: mw_triad@users.sourceforge.net To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBMGAZKVQKGQE4WQQY6Q@isocpp.org Sat Jun 06 09:24:38 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f198.google.com ([209.85.213.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z18T4-0007Zv-FR for gclcip-std-proposals@m.gmane.org; Sat, 06 Jun 2015 09:24:34 +0200 Original-Received: by igcex2 with SMTP id ex2sf57301587igc.0 for ; Sat, 06 Jun 2015 00:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc: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=O614MV8SdppVp8gR5H/NFVn5zNhXDi9DbA0P/hgyBt8=; b=VsGKUJv9xrFB31x6gK18FpzINhBv32heSfvcqCokMmzIM/ludArPHysyZaY9EB2gYO hfSaeI1SkfViLB1UdIYV2n68ulJWBvMf7WJ1aXbKj8HJL0eRy6JrbCYNF0arrIAOdUEH J4iAv9xGY3Nwe4543uJxEVDV483YGrkD5LBbJfk2V1CBg5ZCPgz+Tp0USWvzsANxzZql fqD0wicVfSxYNkLVmxaDWEF/F5REwi3wC6X0QOElC/w+mhFDSlJNZ9iASjm/zymKyboK YMoviPO2DcnYt3GsSKdQCqViJk26J2GjMmGp2kHgAkiUOBaLMy7TcYgY9M5MkQb30VwJ wqew== 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:cc: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=O614MV8SdppVp8gR5H/NFVn5zNhXDi9DbA0P/hgyBt8=; b=PkVKK7U48UxCHY61dB5DpezYk2T3fwlq/WjbO6911nRSbVBAndyMS5K9UHAhd+OnUK YrsSYsl/0B5nyEg30RXOZRAydyI69VPkAgMH/PJewKUO7Imzt9oE9rXhHmMB2/XX58ZI Jzkr9ITgW230Fpv5P/FwamA0hzfyXQk3wjHGjMrmcCZjUJhHSJW8aevjbDOiVuTxANRK frOYy/l6T+5z7JZvZA2lQpukdIQaeThpCCYBzZyj3iVLqvzhtp5dLdwHhYJfeljfH8Au Kb0bBuJ1Oolsw7SCXwwnc7w8jPtI2Q/Ppmne85KnrzfC8o3blanKsA+SBPu8f0ecFu43 BoyQ== X-Gm-Message-State: ALoCoQnyQXLd5M5vMKBYLeUkMRTEnFSxi434dc/dpeQBTXYsJqrJLD6zpYurOix3Ctvqno6zbZQu X-Received: by 10.50.134.202 with SMTP id pm10mr2963986igb.2.1433575473439; Sat, 06 Jun 2015 00:24:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.40.240 with SMTP id x103ls1911889qgx.87.gmail; Sat, 06 Jun 2015 00:24:32 -0700 (PDT) X-Received: by 10.140.22.199 with SMTP id 65mr90245qgn.15.1433575472569; Sat, 06 Jun 2015 00:24:32 -0700 (PDT) In-Reply-To: <55729C6A.7020707@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:18446 Archived-At: ------=_Part_314_1281707761.1433575471831 Content-Type: multipart/alternative; boundary="----=_Part_315_253876070.1433575471831" ------=_Part_315_253876070.1433575471831 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, June 6, 2015 at 3:08:28 AM UTC-4, Vicente J. Botet Escriba=20 wrote: > > Le 05/06/15 20:13, Nicol Bolas a =C3=A9crit : > =20 > On Friday, June 5, 2015 at 1:40:33 PM UTC-4, Matthew Woehlke wrote:=20 >> >> On 2015-06-05 12:01, Nicol Bolas wrote:=20 >> > On Thursday, June 4, 2015 at 11:05:07 AM UTC-4, Matthew Woehlke wrote:= =20 >> >> I think we need expected, but I don't think we should be promoting=20 >> >> it as the One True Method for global error handling. Developers=20 >> >> should continue to use their preferred method for error=20 >> >> propagation. As much as possible, expected should be friendly to=20 >> >> callers that want to turn errors into exceptions.=20 >> >=20 >> > You were doing so well, right up until the last sentence.=20 >> >> So we should *not* make expected as friendly as possible for callers=20 >> that are going to turn it into an exception?=20 >> >> > The choice needs to be made by the caller, yes. But the choice should= =20 >> be=20 >> > made by calling a function that throws exceptions, not by calling some= =20 >> > member of an `expected`. By then, you've already lost some information= =20 >> that=20 >> > the function had about the actual error.=20 >> >> Why? Why does returning an expected necessarily mean that information=20 >> *must* be lost?=20 >> >> As usual, I think you are missing the point. *If and where* expected can= =20 >> be used without losing information, is there still a strong motivation= =20 >> to have a throwing variant? > > > Yes: API consistency. > > There will be APIs where exception information can be lost, and there wil= l=20 > be APIs were information cannot be lost. But that is effectively an=20 > implementation detail, one that should not be visible to the user. The us= er=20 > shouldn't have to know or care that this particular function throws speci= al=20 > exceptions. > > =20 >> > Oh, you can have `.value()` throw if it doesn't hold a value; that's= =20 >> fine.=20 >> > But throwing in such a case should not represent the same thing as the= =20 >> > function actually throwing. It instead represents a caller of the=20 >> > `expected` version who didn't do what he was supposed to do.=20 >> >> Again, why? My understanding is that it is intended that expected be=20 >> usable by callers that just want exceptions, by simply assuming that the= =20 >> expected always has a value. Yes, the exact point at which the exception= =20 >> is thrown is changed (trivially), but I fail to see why that should=20 >> matter.=20 >> >> Look at it differently. Let's say I have a function:=20 >> >> expected foo_expected();=20 >> > =20 >> Let's further say that the exception is exactly what foo_throws() would= =20 >> throw, i.e. no information is lost. Why should I then not write:=20 >> >> T foo_throws() { return foo_expected().value(); } >> > > Because you probably lose elision in this circumstance. > =20 > I don't understand what you mean. Could develop this? > > =20 > And further, if the above is inline, how is it in any way different from= =20 >> writing at the call site:=20 >> >> foo().value() >> > > Because: > > 1) I don't have to see the syntactically useless `.value()` in my code. > =20 > If the function return expected you would have the option > > await f() ? > Yes, because the syntactically useless `await` is much better than the=20 syntactically useless `.value()`. At least .value() isn't *confusing*... My point is that, whatever syntax you put there is more than the nothing=20 you would use if you called a function that actually threw an exception. > 2) API consistency. `foo()` throws; `foo_exp()` returns an `expected`.= =20 > Always (unless _exp doesn't make sense for a particular function). > > 3) Why should `foo_exp` return `exception_ptr` at all? Why should it=20 > construct such a heavy-weight object to contain information the majority = of=20 > which the direct caller of `foo_exp` knows already? Again, going back to= =20 > Filesystem, the filesyste_error exception contains `path` parameters; why= =20 > should a Filesystem function that returns `expected` provide access to=20 > parameters that the caller already knows? > > 4) `.value()` throws the `bad_expected_access` template class. Which= =20 > means that's the type the user normally has to catch (when not using=20 > `exception_ptr`). Which means that catching code needs to recognize that= =20 > the throwing code was using `expected` to do the throwing. Why should it? > =20 > Why not? future behaves this way. Moving from a function that returns= =20 > expected to a function that returns future will have not too much= =20 > consequences on the caller side (if we reach to remove the syntactical=20 > differences - get versus value - or if we provide a monadic interface and= =20 > both classes are mapped to model this concept). > `std::future` throws whatever exception was set into the `promise` it is=20 attached to. The equivalent in `expected` would be `exception_ptr`. And the consequences of using `exception_ptr` in `expected` are pretty=20 substantial. The code looking at the `expected` can't tell anything useful= =20 about the nature of the error; all it knows is that some kind of error took= =20 place. --=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_315_253876070.1433575471831 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, June 6, 2015 at 3:08:28 AM UTC-4, Vicente J. = Botet Escriba wrote:
=20 =20 =20
Le 05/06/15 20:13, Nicol Bolas a =C3=A9crit :
On Friday, June 5, 2015 at 1:40:33 PM UTC-4, Matthew Woehlke wrote:
On 2015-06-05 12:01, Nicol Bolas wrote:
> On Thursday, June 4, 2015 at 11:05:07 AM UTC-4, Matthew Woehlke wrote:
>> I think we need expected, but I don't think we should be promoting
>> it as the One True Method for global error handling. Developers
>> should continue to use their preferred method for error
>> propagation. As much as possible, expected should be friendly to
>> callers that want to turn errors into exceptions.
>
> You were doing so well, right up until the last sentence.

So we should *not* make expected as friendly as possible for callers
that are going to turn it into an exception?

> The choice needs to be made by the caller, yes. But the choice should be
> made by calling a function that throws exceptions, not by calling some
> member of an `expected`. By then, you've already lost some information that
> the function had about the actual error.

Why? Why does returning an expected necessarily mean that information
*must* be lost?

As usual, I think you are missing the point. *If and where* expected can
be used without losing information, is there still a strong motivation
to have a throwing variant?

Yes: API consistency.

There will be APIs where exception information can be lost, and there will be APIs were information cannot be lost. But that is effectively an implementation detail, one that should not be visible to the user. The user shouldn't have to know or care that this particular function throws special exceptions.


> Oh, you can have `.value()` throw if it doesn't hold a value; that's fine.
> But throwing in such a case should not represent the same thing as the
> function actually throwing. It instead represents a caller of the
> `expected` version who didn't do what he was supposed to do.

Again, why? My understanding is that it is intended that expected be
usable by callers that just want exceptions, by simply assuming that the
expected always has a value. Yes, the exact point at which the exception
is thrown is changed (trivially), but I fail to see why that should matter.

Look at it differently. Let's say I have a function:

  expected<T, exception_ptr> foo_expected();

Let's further say that the exception is exactly what foo_throws() would
throw, i.e. no information is lost. Why should I then not write:

  T foo_throws() { return foo_expected().value(); }

Because you probably lose elision in this circumstance.
I don't understand what you mean. Could develop this?

And further, if the above is inline, how is it in any way different from
writing at the call site:

  foo().value()

Because:

1) I don't have to see the syntactically useless `.value()` in my code.
If the function return expected you would have the option

    await f() ?

Yes, beca= use the syntactically useless `await` is much better than the syntactically= useless `.value()`. At least .value() isn't confusing...

My = point is that, whatever syntax you put there is more than the nothing you w= ould use if you called a function that actually threw an exception.
2) API consistency. `foo()` throws; `foo_exp()` returns an `expected`. Always (unless _exp doesn't make sense for a particular function).

3) Why should `foo_exp` return `exception_ptr` at all? Why should it construct such a heavy-weight object to contain information the majority of which the direct caller of `foo_exp` knows already? Again, going back to Filesystem, the filesyste_error exception contains `path` parameters; why should a Filesystem function that returns `expected` provide access to parameters that the caller already knows?

4) `.value()` throws the `bad_expected_access<T>` template class. Which means that's the type the user normally has to catch (when not using `exception_ptr`). Which means that catching code needs to recognize that the throwing code was using `expected` to do the throwing. Why should it?
Why not? future<T> behaves this way. Moving from a function that returns expected<T> to a function that returns future<T> will have not too much consequences on the caller side (if we reach to remove the syntactical differences - get versus value - or if we provide a monadic interface and both classes are mapped to model this concept).

`std::fut= ure` throws whatever exception was set into the `promise` it is attached to= .. The equivalent in `expected` would be `exception_ptr`.

And the con= sequences of using `exception_ptr` in `expected` are pretty substantial. Th= e code looking at the `expected` can't tell anything useful about the natur= e of the error; all it knows is that some kind of error took place.

--

---
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_315_253876070.1433575471831-- ------=_Part_314_1281707761.1433575471831-- .