220 24221 article Path: news.gmane.org!not-for-mail From: "'Edward Catmur' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Proposal: Change the specified behavior when control flow reaches the end of non-void functions Date: Fri, 5 Feb 2016 16:50:39 +0000 Lines: 142 Approved: news@gmane.org Message-ID: References: <5115b78c-8fb4-4c72-a278-f74c636f5217@isocpp.org> <2390270.BM3DFplE2E@tjmaciei-mobl4> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b3a9712a7fdfe052b08a6ab X-Trace: ger.gmane.org 1454691053 27066 80.91.229.3 (5 Feb 2016 16:50:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Feb 2016 16:50:53 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDZLZTXF7UJBBX5F2O2QKGQEDNXIFDA@isocpp.org Fri Feb 05 17:50:47 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aRjak-0000k5-5X for gclcip-std-proposals@m.gmane.org; Fri, 05 Feb 2016 17:50:42 +0100 Original-Received: by mail-ob0-f198.google.com with SMTP id il1sf73998766obb.0 for ; Fri, 05 Feb 2016 08:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=oR0U1YWkpfWkdYrM9auhwc2jBuWO4n2AIEv0vqsC9R4=; b=KvdxrMESJWdWjyHdiYaU6md9nnvib6XY9cnKc8ZoszKo602yRO2O/AJ7TppvRZFr7H g7bSU2StmoNFOfTI5aj+JU2PaWW+0k4Il2xSiftZrdOGTIwMT3fI9mt+RW/O2HOck/TE 9gQqLepqV9dZBIhAZ29A3/+dkBW3XwUp1C3CQLkbNi5Y1Einrm4C6q9tGNSLAfmV5f80 nkc9v0XoutxbYyoGAR0M5lksMZS0Fl4ZPos5AZFIYXgTxgwo1tuE/1XobPTE8lW7zTjJ Y1uf/h9s+vFnTJZ8yiB+5CRpAZAhldmnwmJzv91oarRAnmVbrtyF1+iEw6+ivCje/w0N CjrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=oR0U1YWkpfWkdYrM9auhwc2jBuWO4n2AIEv0vqsC9R4=; b=bvHh6GnTREwGTwkpP2kB1C4umbeEh/nTW1SwRorgsiecZcN5GFqek/5ejZJdsRBrxX j+N0/bpi+BPUl180AnwbXFBWuDKvvupxZ35PPdJHLLZaF6ah8tDwgwUY7f193v68TKCY eroWIrp6S74hJTTn8IPrNluBemlM5D5JMNy4IPWKW3I+sjO3vfzod43a0FOylDwTkDbM VGRgHYkpTourII9ir+g1m4xkBd+2QvAT4zAtsIaT7626GyjTGQXZNCpqIn/+2qycA/HN BVELJ8QuXu4kK9Rpn+tsxUJWEpcWuZp5bDiT5S6P5+7joWdvJGUDe15D8GDovfjn/OZ5 LrGw== X-Gm-Message-State: AG10YOT9dXDSwElqD2sLyFZN5yAQH2D0bji4FCYO8+wSJS7jq7tex3su5OKzMZnJ/OmqXg== X-Received: by 10.107.133.10 with SMTP id h10mr13928125iod.8.1454691041244; Fri, 05 Feb 2016 08:50:41 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.79.166 with SMTP id k6ls263462igx.34.gmail; Fri, 05 Feb 2016 08:50:39 -0800 (PST) X-Received: by 10.50.73.168 with SMTP id m8mr17605239igv.53.1454691039662; Fri, 05 Feb 2016 08:50:39 -0800 (PST) Original-Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com. [2607:f8b0:4001:c05::22b]) by mx.google.com with ESMTPS id qh9si28385783igb.30.2016.02.05.08.50.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Feb 2016 08:50:39 -0800 (PST) Received-SPF: pass (google.com: domain of ecatmur@googlemail.com designates 2607:f8b0:4001:c05::22b as permitted sender) client-ip=2607:f8b0:4001:c05::22b; Original-Received: by mail-ig0-x22b.google.com with SMTP id xg9so17517041igb.1 for ; Fri, 05 Feb 2016 08:50:39 -0800 (PST) X-Received: by 10.50.111.225 with SMTP id il1mr11085970igb.6.1454691039310; Fri, 05 Feb 2016 08:50:39 -0800 (PST) Original-Received: by 10.36.124.76 with HTTP; Fri, 5 Feb 2016 08:50:39 -0800 (PST) In-Reply-To: X-Original-Sender: ecatmur@googlemail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of ecatmur@googlemail.com designates 2607:f8b0:4001:c05::22b as permitted sender) smtp.mailfrom=ecatmur@googlemail.com; dkim=pass header.i=@googlemail.com; dmarc=pass (p=QUARANTINE dis=NONE) header.from=googlemail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , X-Original-From: Edward Catmur Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:24221 Archived-At: --047d7b3a9712a7fdfe052b08a6ab Content-Type: text/plain; charset=UTF-8 On Fri, Feb 5, 2016 at 3:18 PM, Ville Voutilainen < ville.voutilainen@gmail.com> wrote: > In other words, an exception cannot be thrown. It's not just because > it will invoke > terminate anyway that the thread destructor doesn't throw. > There's nothing in the language preventing ~thread throwing; it could e.g. move itself into an exception object, avoiding leaks while giving a handler an opportunity to properly wait on or detach the thread. But in the vast majority of cases you'd just end up with terminate being called anyway, similarly to how Hans Boehm says on http://wg21.cmeerw.net/lwg/issue2135. > >> which is the same situation as we > >> would have with a non-void function falling of its end. > > Why shouldn't a missing return handler throw an exception? Actually, this > > would be another reason not to use std::terminate, as it's nothrow. > > A "return handler"? Well, if you want to propose that the standard provides > a specific handler for such cases, by all means. A non-void function that > fails > to return a value should IMHO not become a throwing function so easily if > it wasn't before. It's a logic error, and throwing an exception that > the programmer > didn't is less likely to be a safe solution than terminating is. Every function not marked nothrow is potentially a throwing function, especially if it allocates memory or interacts with the system in any way. I don't see any reason to consider a missing return an irrecoverable error; it's no worse than calling value() on an empty optional. There is after all a whole class hierarchy in for logic errors. The language throws exceptions to signify recoverable errors in plenty of places: bad_alloc, bad_cast, bad_typeid. > Seems like part of the exception handling mechanism to me. > > You seem to read that text selectively, perhaps in a way suitable for your > local style guide and personal preference, but the > "May also be called directly by the program." part and the fact that > the standard > facilities themself use terminate() when they can't throw disagree > with your view. When they can't throw - it's a fallback for the exception handling mechanism. -- --- 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 https://groups.google.com/a/isocpp.org/group/std-proposals/. --047d7b3a9712a7fdfe052b08a6ab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 5, 2016 at 3:18 PM, Ville Voutilainen <ville.voutilainen= @gmail.com> wrote:
In other words, an exc= eption cannot be thrown. It's not just because
it will invoke
terminate anyway that the thread destructor doesn't throw.

There's nothing in th= e language preventing ~thread throwing; it could e.g. move itself into an e= xception object, avoiding leaks while giving a handler an opportunity to pr= operly wait on or detach the thread. But in the vast majority of cases you&= #39;d just end up with terminate being called anyway, similarly to how Hans= Boehm says on=C2=A0http:/= /wg21.cmeerw.net/lwg/issue2135.
=C2=A0
= >> which is the same situation as we
>> would have with a non-void function falling of its end.
> Why shouldn't a missing return handler throw an exception? Actuall= y, this
> would be another reason not to use std::terminate, as it's nothrow= ..

A "return handler"? Well, if you want to propose that the = standard provides
a specific handler for such cases, by all means. A non-void function that f= ails
to return a value should IMHO not become a throwing function so easily if it wasn't before. It's a logic error, and throwing an exception tha= t
the programmer
didn't is less likely to be a safe solution than terminating is.

Every function not marked nothrow is potentially = a throwing function, especially if it allocates memory or interacts with th= e system in any way. I don't see any reason to consider a missing retur= n an irrecoverable error; it's no worse than calling value() on an empt= y optional. There is after all a whole class hierarchy in <stdexcept>= for logic errors. The language throws exceptions to signify recoverable er= rors in plenty of places: bad_alloc, bad_cast, bad_typeid.

> Seems like part of the exception= handling mechanism to me.

You seem to read that text selectively, perhaps in a way suitable fo= r your
local style guide and personal preference, but the
"May also be called directly by the program." part and the fact t= hat
the standard
facilities themself use terminate() when they can't throw disagree
with your view.

When they can't throw -= it's a fallback for the exception handling mechanism.

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals= /.
--047d7b3a9712a7fdfe052b08a6ab-- .