220 16124 article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?David_Rodr=C3=ADguez_Ibeas?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: deprecate catch exception by value, at least in some instances? Date: Sun, 8 Feb 2015 21:18:20 -0500 Lines: 196 Approved: news@gmane.org Message-ID: References: <8be36e16-97f4-4d8a-8500-c045195b2f6b@isocpp.org> <56A0729B-434D-4300-B4FF-5D744D81506C@gmail.com> <733EB037-F97F-4FB9-8512-1F846C71FA3C@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c16a905761ee050e9e6209 X-Trace: ger.gmane.org 1423448310 7452 80.91.229.3 (9 Feb 2015 02:18:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Feb 2015 02:18:30 +0000 (UTC) To: "std-proposals@isocpp.org" Original-X-From: std-proposals+bncBDIIVO6GQULBB3NR4CTAKGQEHGRYDXQ@isocpp.org Mon Feb 09 03:18:26 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f197.google.com ([209.85.214.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YKdvb-0004OM-8c for gclcip-std-proposals@m.gmane.org; Mon, 09 Feb 2015 03:18:23 +0100 Original-Received: by mail-ob0-f197.google.com with SMTP id wo20sf179303409obc.0 for ; Sun, 08 Feb 2015 18:18:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender: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:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=Z4d05nTNjyiEDzWpQcVIQ6lqDXCL/aY5EA34oOnQmVk=; b=Ic4SSExdvZh38zhSOMhtc5f5oEq9BZB3zuRt/At0xDCW+wd/8esrk9DgjQtSJ01qOn x/sw3qbTaUSt0QMR+pHfLHFSXYiFDif9r9fXwtFpbH/hXGAy0v2wayNBBJTkNd9M+osV jW24gnUTnGU/dxB4DCupd/9vQoE2421pXDdKwu60Uq2Upos63t0zVOZfqdyb90vNUNC4 JOigQC6/9hoyEOnwbtbI78Kj8JwGSofvJMPAxhSAlGheuuXZJg0bSMYrmc8T/SCHVdrf SL4XVj3y+rOuVtzyh+Cdg0q7/2xojTVZPX3Ok4M5YLRPja+b8wKgM5c5waJ1mqNugaJW oE9Q== X-Gm-Message-State: ALoCoQkve2PnVD/lQcRI0MuFlRGJjJ+JEnhStK3GxRKOv+8hDcjPZKVjQ35mJgXykRJUMbXMNTRI X-Received: by 10.182.28.71 with SMTP id z7mr14638385obg.36.1423448302036; Sun, 08 Feb 2015 18:18:22 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.16.173 with SMTP id 42ls1883576qgb.55.gmail; Sun, 08 Feb 2015 18:18:21 -0800 (PST) X-Received: by 10.229.64.67 with SMTP id d3mr21119276qci.9.1423448301229; Sun, 08 Feb 2015 18:18:21 -0800 (PST) Original-Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com. [2607:f8b0:400d:c00::233]) by mx.google.com with ESMTPS id ec7si12537041qcb.23.2015.02.08.18.18.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 08 Feb 2015 18:18:21 -0800 (PST) Received-SPF: pass (google.com: domain of dribeas@gmail.com designates 2607:f8b0:400d:c00::233 as permitted sender) client-ip=2607:f8b0:400d:c00::233; Original-Received: by mail-qa0-f51.google.com with SMTP id i13so578569qae.10 for ; Sun, 08 Feb 2015 18:18:21 -0800 (PST) X-Received: by 10.140.102.82 with SMTP id v76mr34467876qge.32.1423448301066; Sun, 08 Feb 2015 18:18:21 -0800 (PST) Original-Sender: dribeas@gmail.com Original-Received: by 10.140.104.207 with HTTP; Sun, 8 Feb 2015 18:18:20 -0800 (PST) In-Reply-To: <733EB037-F97F-4FB9-8512-1F846C71FA3C@gmail.com> X-Original-Sender: dibeas@ieee.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of dribeas@gmail.com designates 2607:f8b0:400d:c00::233 as permitted sender) smtp.mail=dribeas@gmail.com; dkim=pass header.i=@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:16124 Archived-At: --001a11c16a905761ee050e9e6209 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "On the other hand, catching a base class by value gives the catch block its own modifiable copy. This might not be very useful, and might seldom reflect a strong intent of the programmer, but there=E2=80=99s no other way= to achieve it than to initialize the parameter by value." Well, surely there is one that strongly shows the intent: catch (myexcept const & r) { myexcept copy( r ); =E2=80=A6 But that is, in my opinion, beyond the point. C++ has values, pointers and two types of references; programmers need to be aware of them for building any non-trivial piece of code. Slicing is not a problem limited to exceptions, and exception throwing/catching is not where slicing is more common. This is completely out of the context of exceptions, in this niche you can always give sane simple rules: throw by value, catch by reference [not sure if Microsoft's COM still recommends throwing by pointer=E2=80=A6 = but you should be aware of the idioms for your target platform]. I am not fond of proposals that aim to simplify part of the language in only a small use case. That creates a leaking abstraction, consider that this was allowed, then the compiler would warn/error out when the catch clause but not on the body, leaving this with the same error: catch (myexcept const & ref) { processException(ref); // void processException(myexcept ex) On Sun, Feb 8, 2015 at 8:52 PM, David Krauss wrote: > > On 2015=E2=80=9302=E2=80=9309, at 9:36 AM, gmisocpp@gmail.com wrote: > > I think in my case the issue was that when I was learning C++ I was > confused about pointers and references and values. > i.e. If I threw a pointer was I throwing a copy of the object that I was > pointing to, or just the pointer. > Also since I equated references and pointers in my mind it then wasn't > clear to me then if I threw something I had a reference to, was I actuall= y > throwing a pointer still and should I catch it with a pointer or referenc= e > to handle that. > Add to that, if I catch by value, am I catching my original object thrown > by value or a copy of it, or a copy of a copy. etc. and you can see why > anything that could have stopped me getting into that mental mess might > have been good! > > Hey that all strangely leads me off to a different idea: > When we throw x, why can't we treat that as a move in some instances, lik= e > return does!? > > > My answer to all this would be that 99% of users will only ever throw > prvalue expressions of the form > > throw exception_type{ simple, constants }; > > =E2=80=A6 and although unsafe slicing may occur on catch-by-value, refere= nces > within the sliced base object will tend to refer only into the original > derived exception, which is safely preserved. > > There are users coming from Java who try to put new everywhere, but > that=E2=80=99s just uniformly wrong. > > Throwing expressions of non-class type is a bit silly, but deprecating > that sort of thing smacks of playing thought-police. > > -- > > --- > 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/. > --=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/. --001a11c16a905761ee050e9e6209 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"On the other hand, ca= tching a base class by value gives the catch block its own modifiable copy.= This might not be very useful, and might seldom reflect a strong intent of= the programmer, but there=E2=80=99s no other way to achieve it than to ini= tialize the parameter by value."

Well, surely ther= e is one that strongly shows the intent:

catch (m= yexcept const & r) {
=C2=A0 =C2=A0myexcept copy( r );<= /div>
=E2=80=A6

But that is, in my opinion, be= yond the point.=C2=A0 C++ has values, pointers and two types of references;= programmers need to be aware of them for building any non-trivial piece of= code.=C2=A0 Slicing is not a problem limited to exceptions, and exception = throwing/catching is not where slicing is more common.=C2=A0 This is comple= tely out of the context of exceptions, in this niche you can always give sa= ne simple rules: throw by value, catch by reference [not sure if Microsoft&= #39;s COM still recommends throwing by pointer=E2=80=A6 but you should be a= ware of the idioms for your target platform].

I am= not fond of proposals that aim to simplify part of the language in only a = small use case. That creates a leaking abstraction, consider that this was = allowed, then the compiler would warn/error out when the catch clause but n= ot on the body, leaving this with the same error:

= catch (myexcept const & ref) {
=C2=A0 =C2=A0 processException= (ref); =C2=A0 =C2=A0 =C2=A0 =C2=A0// void processException(myexcept ex)

On Sun, F= eb 8, 2015 at 8:52 PM, David Krauss <potswa@gmail.com> wrote:=

On 2015=E2=80=9302=E2= =80=9309, at 9:36 AM, gmisocpp@gmail.com wrote:

I think in = my case=C2=A0the issue was that when I was learning C++=C2=A0I was confused= about pointers and references and values.
i.e. If I threw a pointe= r=C2=A0was I throwing a copy of the object that I was pointing to, or just = the pointer.
Also since I equated references and pointers in my m= ind=C2=A0it then wasn't clear to me then=C2=A0if I threw something=C2= =A0I had a=C2=A0reference to, was I actually throwing a pointer still and s= hould I catch=C2=A0it with a pointer or reference to handle that.
Add to that, if I catch by value, am I catching my=C2=A0original object th= rown by value or a copy of it, or a copy of=C2=A0a copy. etc. and you can s= ee why anything that could have stopped me getting into that mental mess mi= ght have been good!

Hey that all strangely leads m= e off to a different idea:
When we throw x, why can't we trea= t that as a move in some instances, like return does!?

My answer to all this would be that 99% of = users will only ever throw prvalue expressions of the form

=C2=A0 =C2=A0 throw exception_type{ simple,= constants };

=E2=80=A6 and although unsafe= slicing may occur on catch-by-value, references within the sliced base obj= ect will tend to refer only into the original derived exception, which is s= afely preserved.

There are users coming from Java = who try to put new everywhere, but that=E2=80= =99s just uniformly wrong.

Throwing expressions of= non-class type is a bit silly, but deprecating that sort of thing smacks o= f playing thought-police.

--

---
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-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/gro= up/std-proposals/.

--

---
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>.
--001a11c16a905761ee050e9e6209-- .