220 33524 article Path: news.gmane.org!.POSTED!not-for-mail From: Dejan Milosavljevic Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Catch block for multiple exceptions Date: Wed, 2 Aug 2017 09:04:35 +0200 Lines: 304 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f403045f55de6a929d0555bfe0bb" X-Trace: blaine.gmane.org 1501657478 30167 195.159.176.226 (2 Aug 2017 07:04:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 2 Aug 2017 07:04:38 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDFYFDOFWUGBBBHTQXGAKGQEE3AMPVY@isocpp.org Wed Aug 02 09:04:32 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dcnhn-0007Sg-Lv for gclcip-std-proposals@m.gmane.org; Wed, 02 Aug 2017 09:04:31 +0200 Original-Received: by mail-lf0-f70.google.com with SMTP id g21sf9009484lfg.3 for ; Wed, 02 Aug 2017 00:04:38 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1501657477; cv=pass; d=google.com; s=arc-20160816; b=k1TnDm33UU9+Lc0ZuMA2WAM9GwTAVRYGFYfnzuvn6j92lCgbMH0h5uLTt99sK14gb4 +thakY13VYqqT0CUFreLRdElFP3Wzixt4AO4LWLCb+QdCKNrEegjDYYk5MnChMyv5ZZ/ gUeGs4ywWDuk6uk5//xdtxRRCvFvjW3WZKo2PO5ZsvD99ZPU+pfgwVV8oYUdQWlKuwaL 5LFp9gr9k7fgzc6A/72U3kHfRnCyBTYNuZWFvW1YydhOqfr3oZcUVVtoqbPU+TNzxGvP oZT+HgkI4jqz8ZloopMhtX4AA8zV9xR5YMAfq7g8yyBCl8Y6CU7jYFD0jCyIhY4bJwDp FYUA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=G9nxsEpoU4s/7YYTKjEAtnBNVLlrLv1yYhdImpxF5gI=; b=U/ZDYEecfYN70Zr1G7GWB1ypzGj/PDTNHho12bth/p2ufRcc+vDPORRQgov0QNYVma PnBdmrIjzYPITGOMGxxAvAv9ThdPiF+EV4Ir3e6jqgP8pT0dd1eKXHXF+zgUdROYQoeL 9djtu6rNmtx125seQmLo7xvXwiQCB5S7Kjkuq6yQ/+5Nm7Xo4rvnHpsG2X/kOtQVusbP /Fpw/df5C+zrwLRDrCtR6Pz9ZogzZJRNGg28pYKMPZKNc2zMzmyyVzw8zVtOnyF9qEAb fcc0z8HX5N8Vlf5xvPYA+Zq5kkYMeH/DmGuJYElxSJt2WpNo1yV9Atqxp5Cm+xU+Fuhl sWkA== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.b=aFg/WqfD; spf=pass (google.com: domain of dmilos@gmail.com designates 2a00:1450:400c:c0c::22c as permitted sender) smtp.mailfrom=dmilos@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com 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:from:date:message-id:subject:to :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=G9nxsEpoU4s/7YYTKjEAtnBNVLlrLv1yYhdImpxF5gI=; b=lL3+8u7TgVlQDJz0FxbQ42WcjCYzJ1FUak3x4SOy16FvEeqxm7w5SVHB9rLfwCLq2d tbphPkTcuSRf80lsL1+y7KtRPxjBLz10UwdJx8Hf5+Dye013fDhn+8Pzk37OIG+fdYf+ HnPn/kTtTj5w0CLHTo/MeGLrD06F7mLROyFs3WphyHlTJOqrBrv05BzB+/bf3T5ptBED fTT7HhDXBfIMxmMLgPu4gHeMxqIlU2rC/ZV1cZE9+inwX11ffxCSGqfZWORs76oFZcuD gsGsEDUFSVQbKGKkDWEVkE0BXpAGCI+me2TIGl0ZRiR4Q7uXpkkhhPaj7Ybs1caOgY+I qF1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to: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=G9nxsEpoU4s/7YYTKjEAtnBNVLlrLv1yYhdImpxF5gI=; b=uYu7A9UShkI92MbHL2OT3IaP5YMAl0F/hoi4pWS39b6EtVtHTrSBFrRaNIEYXy6N3D vLKHwQ8CZxYJgBNoMO0Zi2idz7es0wxpQSj3NYKAt6rBvX6a2IjOaNl/U+bWy/x/a+FM 6lnBbYNVTelNx3rSTjUsn46OkbjSUDJckPOU27eLn7t5X5XtTwHCHV2tFmnjZ+XaDXh+ 8Y2itYs6/ypAQV/DgwkfWNpvxdY9GcOloBXAkFMk98mYZeyaDOFFdbeEZnvyq5sicMhX 9rP1BxpAUKqoOPTCbAxbQBO7nJ5hG9Pj7LiitIsE7p7P4gU1GjUfVB/swyegkmz7F5f+ Rlrw== X-Gm-Message-State: AIVw113amF5W8i0BpHccqTP8m9EGZSJEvQjCQ60vW6TlSWKNkmG17up6 5oNIgOrKKqE7pGPk X-Received: by 10.25.181.134 with SMTP id g6mr2288484lfk.3.1501657477818; Wed, 02 Aug 2017 00:04:37 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.4.141 with SMTP id 135ls269257wme.9.gmail; Wed, 02 Aug 2017 00:04:36 -0700 (PDT) X-Received: by 10.80.222.13 with SMTP id z13mr20051503edk.212.1501657476333; Wed, 02 Aug 2017 00:04:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1501657476; cv=none; d=google.com; s=arc-20160816; b=fOTwAt0B54yqo1vOSmy1wCOeoLcGvUIA5O1nq99IgNNlAfXeh07855yodH9pRicGbR 85u9DolqxyzgcdNqJyLqf/Mg9pRfGB73tDx+NCH3EqxTsTGplsIp06ejfykVx9Cz4Fhn T6NxBpuD3LjAZBFkv7MeJS+sUSH+vIR2UTuPkb+2uF/7yQhkluNXZlErg+eBdRtQr1u6 qgO2q3jzgvjENasb4IahSGSLqIhhz/aaO9iTjvFFiAT83NUx5eFyAF3kPE3eoWV4m99S oeI3ki8+hHd0wpQEQhzB+ttQKa3RXcmnE43FAC8S31SZViAftsFs7xebJFlY/0TIiX7k vuqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=FrSUzr3hXQdvVVhA6nsE/PzPNX1cL7/bL5QYPoylLNc=; b=gYGKOZ18kn9DZA5Rc1LT/S2vYXTc1j+INEVFvAXZDbb2efAH/OrtWJ3SCgFAmQxOUB 1V6i/8Yrf2ToxisoXV+LfGEzi3GduovdwpKnnYGMephDioU89UsxOWOD3f9efkRz3T1M UGbJGyi77WYfZkY2LRHSqNfiiEANahxpl1gzfRYY+JapsNPE/WnwCvmsarkgJururQWf tu0rki9AEgyo0qNp+lT0bdM+7E/mtdYuzOCIIfMDRJQkAw/A533FPqTtfG1b++CU5qlk fvGl0bmTCIwdcSud6y1fpl6PG+wZvyZolpdYfQQXiu5eiRtHQgJbI58wf97C36oRJYos dqxg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.b=aFg/WqfD; spf=pass (google.com: domain of dmilos@gmail.com designates 2a00:1450:400c:c0c::22c as permitted sender) smtp.mailfrom=dmilos@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Original-Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com. [2a00:1450:400c:c0c::22c]) by mx.google.com with ESMTPS id m22si8088781edc.125.2017.08.02.00.04.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 02 Aug 2017 00:04:36 -0700 (PDT) Received-SPF: pass (google.com: domain of dmilos@gmail.com designates 2a00:1450:400c:c0c::22c as permitted sender) client-ip=2a00:1450:400c:c0c::22c; Original-Received: by mail-wr0-x22c.google.com with SMTP id f21so14839967wrf.5 for ; Wed, 02 Aug 2017 00:04:36 -0700 (PDT) X-Received: by 10.223.150.208 with SMTP id u74mr16358764wrb.259.1501657475747; Wed, 02 Aug 2017 00:04:35 -0700 (PDT) Original-Received: by 10.28.206.66 with HTTP; Wed, 2 Aug 2017 00:04:35 -0700 (PDT) In-Reply-To: X-Original-Sender: dmilos@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.b=aFg/WqfD; spf=pass (google.com: domain of dmilos@gmail.com designates 2a00:1450:400c:c0c::22c as permitted sender) smtp.mailfrom=dmilos@gmail.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=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:33524 Archived-At: --f403045f55de6a929d0555bfe0bb Content-Type: text/plain; charset="UTF-8" catch (exceptionA, exceptionB, exceptionC e) { f(e); } Questions: - How to know which exception invoke this catch? - If catch was invoked by exceptionA what is the content of exceptionC? On Tue, Aug 1, 2017 at 7:50 PM, Nicol Bolas wrote: > On Tuesday, August 1, 2017 at 1:04:21 PM UTC-4, david.b...@gmail.com > wrote: >> >> If you need to handle multiple exceptions you write catch block per every >> exception. >> >> Example: >> >> try { >> ... >> } catch (exceptionA e) { >> // handle expetionA >> f(); >> } >> >> >> } catch (exceptionB e) { >> // handle exceptionB >> f(); >> } >> >> >> } catch (exceptionC e) { >> // handle exceptionC >> f(); >> } >> >> >> } catch (exceptionD e) { >> // handle exceptionD >> g(); >> } >> >> >> >> >> If e.g. exception A, B, C could be handled via the same logic (e.g >> function "f"), we are copy-pasting exception-handling code (callinf f() in >> this case) in particular catch blocks. >> >> >> To avoid that, proposed improvment could be: >> >> >> try { >> ... >> } catch (exceptionA, exceptionB, exceptionC) { >> // handle exception (does not matter whether exception A, B or C - >> we have same handling code for them) >> f(); >> } >> >> } catch (exceptionD e) { >> // handle exceptionD >> g(); >> } >> >> >> >> > So, here's a question: why would you have this circumstance? That is, 3 > completely unrelated exception types require the exact same handling code > (to the point where they don't even use the exception object itself), while > simultaneously there is a fourth exception type which requires different > handling code. What could possibly cause such a thing? > > Decent use of RAII eliminates 99% of `catch` statements for the purpose of > cleanup. That leaves behind work based on the specific kind of exception. I > could imagine a database throwing a transaction failure exception as well > as an out of memory exception. You need different code to handle those > (assuming you want to handle OOM at all). > > But why would such a database have multiple unrelated transaction failure > exception types? Or multiple unrelated memory exception types? Generally > speaking, we allow users to catch related exceptions in the same statement > by using inheritance from a common exception type. If a database had > multiple kinds of transaction failures, they should all be derived from a > root "transaction failure" exception. > > So I find the use case to be dubious. Can you provide a more concrete, > less hypothetical example? > > >> With the instance of one of those exceptions: >> catch (exceptionA, exceptionB, exceptionC e) { >> f(e); >> } >> >> > That's rather more disconcerting. You now need code to be validated > against 3 unrelated types. Effectively, you're instantiating a template, > but only from a certain set of types. > > I don't much care for that either. > > -- > 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. > To view this discussion on the web visit https://groups.google.com/a/ > isocpp.org/d/msgid/std-proposals/deaedeb0-a699-49e9- > 826a-c41e674902c0%40isocpp.org > > . > -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmzCWDwP2ha7UfvvPrW_56TT4DEgvwRyxWm%3D6gS_GZc7pA%40mail.gmail.com. --f403045f55de6a929d0555bfe0bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

catch (exceptionA, e= xceptionB, exceptionC e) {
=C2=A0=C2=A0 f(e);
}

Question= s:

- How to know which exception invoke this catch?
- If catch was= invoked by exceptionA what is th= e content of exceptionC?


On Tue, Aug 1, 2= 017 at 7:50 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
On= Tuesday, August 1, 2017 at 1:04:21 PM UTC-4, david.b...@gmail.com wrote:
If you need to handle multiple exceptions you write catc= h block per every exception.

Example:

=
try {=
=C2=A0 =C2=A0 =C2=A0 ...
<= /span>} catch (= exceptionA e) {
=C2= =A0 =C2=A0 =C2=A0// handle expeti= onA
=C2=A0 =C2=A0 =C2=A0f= ();
}


= } catch (exceptio= nB e) {
=C2=A0 =C2=A0 =C2=A0// handle exceptionB
=C2=A0 =C2=A0 =C2=A0f();
}


} = catch (exceptionC e) {
=C2=A0 =C2=A0 = =C2=A0// handle exceptionC=
=C2=A0 =C2=A0 =C2=A0f();
<= /span>}


} c= atch (exceptionD e<= span style=3D"color:rgb(102,102,0)">) {
=C2=A0 =C2=A0 =C2=A0// handle exceptionD
=C2=A0 = =C2=A0 =C2=A0g();
}=

<= div>


If e.g. exception A, B, C could be ha= ndled via the same logic (e.g function "f"), we are copy-pasting = exception-handling code (callinf f() in this case) in particular catch bloc= ks.


To avoid that, proposed improvm= ent could be:

=
try {
=C2=A0 =C2=A0 =C2=A0 ...
} catch (exceptionA, exceptionB, excepti= onC) {
=C2=A0 =C2=A0 =C2=A0// handle exception (does not matter whether exception A, B = or C - we have same handling code for them)
=C2=A0 =C2=A0 =C2=A0f();
}

<= span style=3D"color:rgb(102,102,0)">} catch (exceptionD e) {
=C2=A0 =C2= =A0 =C2=A0// handle exceptionD
=C2=A0 =C2=A0 =C2=A0g();<= br>}




So, here's a question: why would y= ou have this circumstance? That is, 3 completely unrelated exception types = require the exact same handling code (to the point where they don't eve= n use the exception object itself), while simultaneously there is a fourth = exception type which requires different handling code. What could possibly = cause such a thing?

Decent use of RAII eliminates 99% of `catch` sta= tements for the purpose of cleanup. That leaves behind work based on the sp= ecific kind of exception. I could imagine a database throwing a transaction= failure exception as well as an out of memory exception. You need differen= t code to handle those (assuming you want to handle OOM at all).

But= why would such a database have multiple unrelated transaction failure exce= ption types? Or multiple unrelated memory exception types? Generally speaki= ng, we allow users to catch related exceptions in the same statement by usi= ng inheritance from a common exception type. If a database had multiple kin= ds of transaction failures, they should all be derived from a root "tr= ansaction failure" exception.

So I find the use case to be dubi= ous. Can you provide a more concrete, less hypothetical example?


<= div>With the instance of one of =C2=A0those exceptions:
<= code>
catch (exceptionA, exceptionB, excepti= onC e) {
=C2=A0 =C2=A0f(e);
}


That's rather more disconcerting. You now need code to be valida= ted against 3 unrelated types. Effectively, you're instantiating a temp= late, but only from a certain set of types.

I don't much care fo= r that either.

--
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.
 To view this discussion on the web visit = https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/deae= deb0-a699-49e9-826a-c41e674902c0%40isocpp.org.

--
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.
To view this discussion on the web visit h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAEfefmzCWDwP2h= a7UfvvPrW_56TT4DEgvwRyxWm%3D6gS_GZc7pA%40mail.gmail.com.
--f403045f55de6a929d0555bfe0bb-- .