220 18424 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 11:13:32 -0700 (PDT) Lines: 219 Approved: news@gmane.org Message-ID: 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/mixed; boundary="----=_Part_501_424784161.1433528012621" X-Trace: ger.gmane.org 1433528023 20548 80.91.229.3 (5 Jun 2015 18:13:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jun 2015 18:13:43 +0000 (UTC) Cc: mw_triad@users.sourceforge.net To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBTONY6VQKGQEOJKUCWY@isocpp.org Fri Jun 05 20:13:41 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f199.google.com ([209.85.214.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z0w7f-0005Ao-UL for gclcip-std-proposals@m.gmane.org; Fri, 05 Jun 2015 20:13:40 +0200 Original-Received: by obcds4 with SMTP id ds4sf101276823obc.2 for ; Fri, 05 Jun 2015 11:13:34 -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=IK+MTbD4OcTJROONDGtyDk6Q6wcvQM4StLy91cxuNs8=; b=utvjM4RjFXXRc3XI00iBtfuFkTQj587DPOLBE7jCtF7XJ3p2j+rrmqDBJlBKrtDcjC ODCrJq76zYf7UDod4AjmIi2HG4emWNH7vlHwXsl6pvb+x7YQbIq/B3sfPdv8tXVxbRfq IPqjnAN3bTOuZ4Pxh80Wtu6g7mtWbsGmRpQ4t2MKgjZ/2pwBjNjudCnIo4OK4OiM4p0W R0lWjbTAqkCiJldYigpC1IBDBEV9Ng2EZSeRB7Y6DOm1sry0UEzobw3xY6j63rqibHVb ExSpAk3ScajCmUBesPb2HmH/gFf3PX9m+JxCBsPpAoiB5GdTNpxUBJVfEeH4YGhXNNWs yWKg== 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=IK+MTbD4OcTJROONDGtyDk6Q6wcvQM4StLy91cxuNs8=; b=iE9PvJKLcLfsuzywlICVHz+jh8CPo3TrseRgkqYCRQCCys0RJMRHz3wsngvd4CTQYy NtJxHrv0fB911u+9P5mthG+MBdJrnvVdS32ktt3Xj0NORcurUrzIWNP5/HUDMKQ0E7KQ pEXqMhmNPSOZdngzO4CrjhoGM3a1bjnwvpliFVXkjL1RksEkFBbYmtB34hQIl8QULBAx XgMBl3vkf12XosTVr6lndr7TXln7jFezOhRwjGUg7rF4X4XOv8qbE3vEgd7ObPC0NuVZ hl1W7dzpigtT2uQQYRvoY4l0Ypn2FtqvOi7iFJdStY/y6ixlfP4+uOEoVIgMLfya/iWQ XzXA== X-Gm-Message-State: ALoCoQnhN7l6kBfqMMquUM/5f1sVt7L+Rhs+x6s7U7clhtpWOUV37st9DM7OataMjBsI5kdRS8W1 X-Received: by 10.42.129.73 with SMTP id p9mr12866221ics.19.1433528013937; Fri, 05 Jun 2015 11:13:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.81.40 with SMTP id e37ls1684417qgd.4.gmail; Fri, 05 Jun 2015 11:13:33 -0700 (PDT) X-Received: by 10.140.104.48 with SMTP id z45mr61835qge.22.1433528013186; Fri, 05 Jun 2015 11:13:33 -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:18424 Archived-At: ------=_Part_501_424784161.1433528012621 Content-Type: multipart/alternative; boundary="----=_Part_502_1111751299.1433528012621" ------=_Part_502_1111751299.1433528012621 Content-Type: text/plain; charset=UTF-8 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 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. 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. 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` 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? 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. -- --- 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 email 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-proposals/. ------=_Part_502_1111751299.1433528012621 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Friday, June 5, 2015 at 1:40:33 PM UTC-4, Matthew Woehl= ke wrote:
On 2015-06-05 12:01, = Nicol Bolas wrote:
> On Thursday, June 4, 2015 at 11:05:07 AM UTC-4, Matthew Woehlke wr= ote:
>> I think we need expected, but I don't think we should be promo= ting
>> it as the One True Method for global error handling. Developer= s
>> should continue to use their preferred method for error=20
>> propagation. As much as possible, expected should be friendly = to
>> callers that want to turn errors into exceptions.
>=20
> 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 sho= uld 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 informa= tion that=20
> 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 ca= n
be used without losing information, is there still a strong motivation
to have a throwing variant?

Yes: API consistency.<= br>
There will be APIs where exception information can be lost, and ther= e 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 specia= l exceptions.


> Oh, you can have `.value()` throw if it doesn't hold a value; that= 's 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.

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

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.

<= /div>
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.

2) AP= I consistency. `foo()` throws; `foo_exp()` returns an `expected`. Always (u= nless _exp doesn't make sense for a particular function).

3) Why sho= uld `foo_exp` return `exception_ptr` at all? Why should it construct such a= heavy-weight object to contain information the majority of which the direc= t caller of `foo_exp` knows already? Again, going back to Filesystem, the f= ilesyste_error exception contains `path` parameters; why should a Filesyste= m function that returns `expected` provide access to parameters that the ca= ller already knows?

4) `.value()` throws the `bad_expected_access<= ;T>` template class. Which means that's the type the user normally has t= o catch (when not using `exception_ptr`). Which means that catching code ne= eds to recognize that the throwing code was using `expected` to do the thro= wing. Why should it?

As a throwing interface, `expected` is sub-opti= mal. And this is as it should be. Let the caller decide by picking the prop= er function to call, not by what `expected` throws.

--

---
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_502_1111751299.1433528012621-- ------=_Part_501_424784161.1433528012621-- .