220 18444 <55729C6A.7020707@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Thoughts on Exceptions, Expected, and Error Handling Date: Sat, 06 Jun 2015 09:08:26 +0200 Lines: 365 Approved: news@gmane.org Message-ID: <55729C6A.7020707@wanadoo.fr> References: <1d83a5df-f8b1-41fc-a197-319825b5436d@isocpp.org> <97c9b3aa-44b4-4a63-92a0-a571628b0735@isocpp.org> <303e5cc6-8a3e-4063-880e-eac448ec0dc6@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------040003090700040501020102" X-Trace: ger.gmane.org 1433574518 11917 80.91.229.3 (6 Jun 2015 07:08:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Jun 2015 07:08:38 +0000 (UTC) Cc: mw_triad@users.sourceforge.net To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBB25YZKVQKGQEHQTGL4Q@isocpp.org Sat Jun 06 09:08:30 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wg0-f72.google.com ([74.125.82.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z18DU-0001Ec-SB for gclcip-std-proposals@m.gmane.org; Sat, 06 Jun 2015 09:08:28 +0200 Original-Received: by wgla2 with SMTP id a2sf22367836wgl.1 for ; Sat, 06 Jun 2015 00:08:28 -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 :cc: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=Vsn4yVTZTYpI4fRh3S4gkEaX+YzwjAKFp1rL0En4Mzc=; b=CxGKSCmRzOqcNftz9uGFABbYNxdAkwhUuqE/lv804Wum0uRO8kwFAd+NIKHGIh9U6Y 71vmoJtYx34c3fC6ZX1gMftw/1byxRUWrACIR0ZaAgt5ptxqxyU1dBbtUY4DrwKVAb6u y0ZI+h3jwvHZxL6SSCqs+Wmmc0R9CgUf9TNF/Xg9cuOpD3dAUgfcuBQpGt7i+YvGbuRI pAFAH7CL/LCDR7ZtVzcMSALnQvwtnAAgpD+3NE/VdqfOdDc/Kzc3G2yU7pCWd2kcASI3 C2JnGxL0bSkb8rWIZkm8mrXj20KkaO3XmHFqjn8eUQfSUS2fCaNR6TYtHFmvYSlnzyuF kStg== X-Gm-Message-State: ALoCoQlqozZWtbwoSRWYXZVVChjqIdl05zkYai2S4bNxvSimbhnmTUonBhRoYk+nbx2PNXj3ruwA X-Received: by 10.194.175.36 with SMTP id bx4mr6735231wjc.1.1433574508394; Sat, 06 Jun 2015 00:08:28 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.106.71 with SMTP id gs7ls567777wib.43.gmail; Sat, 06 Jun 2015 00:08:27 -0700 (PDT) X-Received: by 10.194.176.201 with SMTP id ck9mr13000024wjc.108.1433574507474; Sat, 06 Jun 2015 00:08:27 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr. [80.12.242.124]) by mx.google.com with ESMTPS id rw6si17232725wjb.95.2015.06.06.00.08.27 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 06 Jun 2015 00:08:27 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.124 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.124; Original-Received: from new-host.home ([2.11.252.224]) by mwinf5d25 with ME id cv8S1q00t4rF3xu03v8SP3; Sat, 06 Jun 2015 09:08:27 +0200 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Sat, 06 Jun 2015 09:08:27 +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: X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.124 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:18444 Archived-At: This is a multi-part message in MIME format. --------------040003090700040501020102 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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=20 > will be APIs were information cannot be lost. But that is effectively=20 > an implementation detail, one that should not be visible to the user.=20 > The user shouldn't have to know or care that this particular function=20 > 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 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() ? > > 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=20 > majority of which the direct caller of `foo_exp` knows already? Again,=20 > going back to Filesystem, the filesyste_error exception contains=20 > `path` parameters; why should a Filesystem function that returns=20 > `expected` provide access to parameters that the caller already knows? > > 4) `.value()` throws the `bad_expected_access` template class.=20 > Which means that's the type the user normally has to catch (when not=20 > using `exception_ptr`). Which means that catching code needs to=20 > recognize that the throwing code was using `expected` to do the=20 > throwing. Why should it? 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=20 and both classes are mapped to model this concept). > > As a throwing interface, `expected` is sub-optimal. And this is as it=20 > should be. Let the caller decide by picking the proper function to=20 > call, not by what `expected` throws. I guess that we are talking here about a concrete case of C++ standard=20 library interface, e.g. for FileSystem and not of a general case (sorry=20 if I missed the context of the thread). Vicente P.S. I have started the thread from the beginning now. --=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/. --------------040003090700040501020102 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 05/06/15 20:13, Nicol Bolas a =C3=A9crit=C2=A0:
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:

=C2=A0 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:

=C2=A0 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:

=C2=A0 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

=C2=A0=C2=A0=C2=A0 await f() ?

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


As a throwing interface, `expected` is sub-optimal. And this is as it should be. Let the caller decide by picking the proper function to call, not by what `expected` throws.
I guess that we are talking here about a concrete case of=C2=A0 C++ standard library interface, e.g. for FileSystem and not of a general case (sorry if I missed the context of the thread).

Vicente

P.S. I have started the thread from the beginning now.

--

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