220 18481 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: Sun, 7 Jun 2015 00:40:18 -0700 (PDT) Lines: 335 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> <557215EF.9060006@wanadoo.fr> <5572D2B0.60400@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1109_137183782.1433662818758" X-Trace: ger.gmane.org 1433662835 16065 80.91.229.3 (7 Jun 2015 07:40:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Jun 2015 07:40:35 +0000 (UTC) Cc: mw_triad@users.sourceforge.net To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBZPKZ6VQKGQELI6ZCZQ@isocpp.org Sun Jun 07 09:40:23 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qk0-f199.google.com ([209.85.220.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z1VBu-00072j-T1 for gclcip-std-proposals@m.gmane.org; Sun, 07 Jun 2015 09:40:23 +0200 Original-Received: by qkhe13 with SMTP id e13sf122479839qkh.1 for ; Sun, 07 Jun 2015 00:40:21 -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=4imlntYAL5Q44hQaX/0sB0wkohTULW+zrZfcanYqeLw=; b=UA3H++gY1VC9SRTDdKw5hM0skgvqf30yHZt7+dvPPD7sB1FJWQZiL7hMXB10zYqhUB TE6YkQAgROcOllEOyWyia8tZ7H7d5xxmoy5mQIcqrFfP6cQ15o3z9VxiO+pSHSFOf3U0 YW+9ONu9rvOZ4VNSGnB/kfFu1NJ7s3Y8SIfeTxDiquh6DkzJ0yBBozNYT9HdO81W4qJD /GuHNVbLWVdc34Q9zus9jCmTAMKTmmoOVdYfwKf8ptzheCdsajBRgy+71CKf7DDT+lWe Pzm9W2a8MGQ9LVFresOuNTYk28/gKeWusiNykiAK1Lokrl5u9PPfPpSSZ4Agv4+LPSTO jEaQ== 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=4imlntYAL5Q44hQaX/0sB0wkohTULW+zrZfcanYqeLw=; b=Bzyyt1RPhEg4BehHeYg5ZoS6UPpGL3e0w5tSz4A/YLEq2LdD8o/X865meqUvqbelBj 648VSSsy8HqxOk+h43bxrYLiBRmJWP8oHA0p9OoCBn/ltIHm5yiIhe1H8+fAMQywj0Xt gijUHH178NduYOgTU6tKoimfnfZoenyXTrd70cz8TVREaXqTG86jf/gUea9foVnv0VCd XmP82ilItJ9aWCIqYvPp5Jb6HNZgaTkp9SW+xpZ33nlRqTa5WN6XXNBLu2+44S79wOUH ydQuH9gJ1NlCOVcVKPqyXPmPn+7qd8vNwu0Ie5AONBeRMSOL7RWWlZrs2xH4HKsQXVlc fWsw== X-Gm-Message-State: ALoCoQljFuZvuuFABLolajv0i+OxtaCwNp9e/l7yLk+Dby12FOPa0IWnbLS+TK/PIgCSHwNDP2Xb X-Received: by 10.129.48.69 with SMTP id w66mr11180515yww.20.1433662821778; Sun, 07 Jun 2015 00:40:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.38.116 with SMTP id s107ls2435315qgs.20.gmail; Sun, 07 Jun 2015 00:40:21 -0700 (PDT) X-Received: by 10.140.33.76 with SMTP id i70mr129417qgi.14.1433662821228; Sun, 07 Jun 2015 00:40:21 -0700 (PDT) In-Reply-To: <5572D2B0.60400@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:18481 Archived-At: ------=_Part_1109_137183782.1433662818758 Content-Type: multipart/alternative; boundary="----=_Part_1110_1397870843.1433662818759" ------=_Part_1110_1397870843.1433662818759 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, June 6, 2015 at 7:00:03 AM UTC-4, Vicente J. Botet Escriba=20 wrote: > > Le 06/06/15 09:19, Nicol Bolas a =C3=A9crit : > =20 > On Friday, June 5, 2015 at 6:42:30 PM UTC-4, Matthew Woehlke wrote:=20 >> >> On 2015-06-05 17:34, Vicente J. Botet Escriba wrote:=20 >> > Le 05/06/15 21:19, Nicol Bolas a =C3=A9crit :=20 >> >> OK, so... what about static analysis tools? We already have great=20 >> >> static tools that can detect the use of many uninitialized values.=20 >> >=20 >> > expected as optional, and I hope would variant, are never uninitialize= d=20 >> > as these classes have default constructor.=20 >> >> Not the expected/optional itself, but the contained value.=20 >> >> IOW, this is a (potential) error:=20 >> >> auto x =3D function_that_returns_expected_or_optional;=20 >> do_something(x.value());=20 >> >> ...because you didn't check that 'x' actually *has* a value, and thus=20 >> value() might throw.=20 >> >> Nicol is of the opinion that one should never write code like this, even= =20 >> if throwing from the context where value() is called if there is no=20 >> value is the intended behavior.=20 >> >> I have to ask, though: in that case, why throw at all? >> > > Because "wrong" doesn't necessarily mean "shouldn't be allowed." > > Sometimes, some piece of code winds up with an `expected` that doesn't=20 > have its value, and that code's precondition is that it should have a=20 > value. The code doesn't check it because it shouldn't be possible, but=20 > maybe they've done something that defeats the static analysis tool (or=20 > their compiler isn't smart enough to find it for them). But for whatever= =20 > reason, this code bug has happened. > > if there is a precondition that there is a value, the function should= =20 > take a T as parameter not an expected. > You're assuming it's a "function" rather than just "code". A particular=20 piece of code has preconditions too, things that it assumes have happened,= =20 so it doesn't check for them. > Really, I envision expected as a 'delayed throw' mechanism. The point= =20 >> is=20 >> to return an expected instead of throwing immediately, and instead delay= =20 >> *the throw that otherwise would have happened* until the user calls=20 >> value(), thus giving a window where the user can choose to handle the=20 >> error before an exception is thrown. >> > > Well, a lot of the functional programming crowd in this thread seems to= =20 > think that `expected` objects should be flying up the call-stack via=20 > `await` shenanigans or whatever. So there's some disagreement here as to= =20 > how `expected` ought to be used. > > Why you want to tell to the user how it must use expected? This is not= =20 > up to the standard. > Of course it is. It's a decision of the standard to allow `value` to throw= =20 at all. Therefore, the standard says how you can use `value`. People are suggesting that `await` should be grafted onto `expected` as=20 well. Others are suggesting some "pattern matching" syntax or some such.=20 These are all very much ways the standard tells users how a type may be=20 used. =20 > I see `expected` as how I described it in my look at it: an alternate=20 > way to pass an error directly to the local calling scope. > > There are several problems with thinking of `expected` as merely a delaye= d=20 > throwing mechanic. Part of it has to do with what goes into the error cod= e=20 > portion. > > As previously stated, exceptions often need rich information, since they= =20 > are usually processed far from their invocation site. `expected` objects= =20 > are usually processed close enough that the local code can get much of th= is=20 > information themselves. In those cases, a simple std::error_condition is= =20 > often sufficient. > > Something like `exception_ptr` is completely opaque; the only thing you= =20 > can do with that is throw it. You can't inspect it to find out which=20 > exception was captured or anything. Even a shared pointer to some object = is=20 > problematic because you're having to allocate memory just to pass an erro= r. > =20 > std::variant is an valid alternative. It is equivalent to exception=20 > specifications. I prefer yet std::any that as the ABI don't changes when= =20 > new errors are added. Neither of them forces an allocation. > std::any very much does do memory allocation. Oh, implementations may have= =20 some small-object-optimization in its storage. But that's a QOI issue; just= read=20 the spec=20 .=20 Implementations "should avoid the use of dynamically allocated memory for a= =20 small contained object". How big "small" is is a QOI issue. And since we're= =20 talking about arbitrary objects, you can't guarantee that. --=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_1110_1397870843.1433662818759 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Saturday, June 6, 2015 at 7:00:03 AM UTC-4, Vic= ente J. Botet Escriba wrote:
=20 =20 =20
Le 06/06/15 09:19, Nicol Bolas a =C3=A9crit :
On Friday, June 5, 2015 at 6:42:30 PM UTC-4, Matthew Woehlke wrote:
On 2015-06-05 17:34, Vicente J. Botet Escriba wrote:
> Le 05/06/15 21:19, Nicol Bolas a =C3=A9crit :
>> OK, so... what about static analysis tools? We already have great
>> static tools that can detect the use of many uninitialized values.
>
> expected as optional, and I hope would variant, are never uninitialized
> as these classes have default constructor.

Not the expected/optional itself, but the contained value.

IOW, this is a (potential) error:

  auto x =3D function_that_returns_expected_or_optional= ;
  do_something(x.value());

...because you didn't check that 'x' actually *has* a value, and thus
value() might throw.

Nicol is of the opinion that one should never write code like this, even
if throwing from the context where value() is called if there is no
value is the intended behavior.

I have to ask, though: in that case, why throw at all?

Because "wrong" doesn't necessarily mean "shouldn't be allowed."

Sometimes, some piece of code winds up with an `expected` that doesn't have its value, and that code's precondition is that it should have a value. The code doesn't check it because it shouldn't be possible, but maybe they've done something that defeats the static analysis tool (or their compiler isn't smart enough to find it for them). But for whatever reason, this code bug has happened.

if there is a precondition that there is a value, the function should take a T as parameter not an expected<T>.

You're assuming it's a "function" rather than just "code". A= particular piece of code has preconditions too, things that it assumes hav= e happened, so it doesn't check for them.
Really, I envision expected as a 'delayed throw' mechanism. The point is
to return an expected instead of throwing immediately, and instead delay
*the throw that otherwise would have happened* until the user calls
value(), thus giving a window where the user can choose to handle the
error before an exception is thrown.

Well, a lot of the functional programming crowd in this thread seems to think that `expected` objects should be flying up the call-stack via `await` shenanigans or whatever. So there's some disagreement here as to how `expected` ought to be used.

Why you want to tell to the user how it must use expected? This is not up to the standard.

Of course it is.= It's a decision of the standard to allow `value` to throw at all. Therefor= e, the standard says how you can use `value`.

People are suggesting = that `await` should be grafted onto `expected` as well. Others are suggesti= ng some "pattern matching" syntax or some such. These are all very much way= s the standard tells users how a type may be used.
 
I see `expected` as how I described it in my look at it: an alternate way to pass an error directly to the local calling scope.

There are several problems with thinking of `expected` as merely a delayed throwing mechanic. Part of it has to do with what goes into the error code portion.

As previously stated, exceptions often need rich information, since they are usually processed far from their invocation site. `expected` objects are usually processed close enough that the local code can get much of this information themselves. In those cases, a simple std::error_condition is often sufficient.

Something like `exception_ptr` is completely opaque; the only thing you can do with that is throw it. You can't inspect it to find out which exception was captured or anything. Even a shared pointer to some object is problematic because you're having to allocate memory just to pass an error.
std::variant is an valid alternative. It is equivalent to exception specifications. I prefer yet std::any that as the ABI don't changes when new errors are added. Neither of them forces an allocation.

std::any very much does do memory allocation. Oh, = implementations may have some small-object-optimization in its storage. But= that's a QOI issue; just read the spec. Implementations = "should avoid the use of dynamically allocated memory for a small contained= object". How big "small" is is a QOI issue. And since we're talking about = arbitrary objects, you can't guarantee that.

--

---
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_1110_1397870843.1433662818759-- ------=_Part_1109_137183782.1433662818758-- .