220 33512 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Catch block for multiple exceptions Date: Tue, 1 Aug 2017 10:50:47 -0700 (PDT) Lines: 244 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/mixed; boundary="----=_Part_5163_2138062996.1501609847427" X-Trace: blaine.gmane.org 1501609856 30329 195.159.176.226 (1 Aug 2017 17:50:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 1 Aug 2017 17:50:56 +0000 (UTC) Cc: david.bolvansky@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB6H6QLGAKGQESDNVBJY@isocpp.org Tue Aug 01 19:50:51 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f197.google.com ([209.85.161.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dcbJb-0007F9-92 for gclcip-std-proposals@m.gmane.org; Tue, 01 Aug 2017 19:50:43 +0200 Original-Received: by mail-yw0-f197.google.com with SMTP id c13sf36684118ywa.2 for ; Tue, 01 Aug 2017 10:50:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=qQW6kvkvcj5M/chJRkxXxIeLy1LUeYvOhaK9xFypXPc=; b=iujEfXDzF8aFtEXo5opqPiMMu48MruL+mQwtSm00sJWYqOwuBcbkT4QzO7cDbVtW4L D3WTyYsVKonnDKkUSOkz1XReQCJnqAnTooaZyX8mY2YHmBk5oUjI3v3QgArsdrIgyKeM 3QEzumo82l3mOWxd+VQdznNj8RPbbVY5W0oU8GwHfIBdNElaX/mWeEcr0z4fEEJmH+cC uljkIilRc+mH5iw3ZQks1g1Ze5vTIyc667/n36VGbGBUSTrkeW03RjMW459YVHBdRMt5 YPF3lbiEL9MoaA9PJTbnmqcwqufKFRSE1/PchWkY/OW/Qgad9vyM8qZihko1cKQhFe11 2n8A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=qQW6kvkvcj5M/chJRkxXxIeLy1LUeYvOhaK9xFypXPc=; b=AGCHrFpu0o93x6HKEuoyc7MaRmI7+cOiwayiDEjWZScYEyZM+6lqOnJPKDmUYq7SHc k6nEY/S8oOAKI4i9oiIcaNwf2nriB4Kah7vzYli9v+9wkdlKZgjU3iCVBGaav2GNC++i 9xEwo9KfZBXRrnpIno0F0vV8LXTC+Qkl+i9dB8ce6n6gU7U5zzCkdizGTDBYaxKkp/yy 1PU92QU4bDV2ISD2/Ml7joj7HjHEG9YP0W9YiAtankYoVO67Gx6DlrgoEiYgS7Gh3t6u /2qT/oEUuADzo2Qi7WGqoamFV35/pYjq7KOS+q7QMwiugMBCbpfeA3eKRHK+3ujzlTIL 8C8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=qQW6kvkvcj5M/chJRkxXxIeLy1LUeYvOhaK9xFypXPc=; b=BREkZX4ALy5/o2Li6EysSZ1h6oc8qaRyvXLZVy/TSf5sOfVQEEShuuhD9hyK+D7V3R 5G1JokglSkmd1PWuV9+uF7rdMB/mmAr1MTldSHuiBbk4vagUBRT3QUFaCA1fRue26xOq AAYOwtJ983y1Z3gYYXiH8isFJtrSoRXSQZ9fvb3MaJGH8dE4XRwSZf8c+GCPhvjnTFcK CYLUnEIjVmzVspNlsXILVgM2Y/A1TuJVSB84/Y45zK6NQQy1MyUdk9SmAPFl51oylz4H iTiYPvsSJIP5kJQ07jsf3sY/Yx4PUmZ8goh3RYGHge1d2sHolOeNm7xWZeODdoyY010y eR6A== X-Gm-Message-State: AIVw113RSky2cWC0BuLIFKKiin04J1GHa82mRvrcFOuxPmsZdchr6RU0 EiA+7AGFzvEjMtne X-Received: by 10.129.102.215 with SMTP id a206mr12623945ywc.144.1501609849091; Tue, 01 Aug 2017 10:50:49 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.24.69 with SMTP id 66ls10931990ioy.18.gmail; Tue, 01 Aug 2017 10:50:47 -0700 (PDT) X-Received: by 10.31.77.2 with SMTP id a2mr102766vkb.5.1501609847868; Tue, 01 Aug 2017 10:50:47 -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:33512 Archived-At: ------=_Part_5163_2138062996.1501609847427 Content-Type: multipart/alternative; boundary="----=_Part_5164_37121966.1501609847428" ------=_Part_5164_37121966.1501609847428 Content-Type: text/plain; charset="UTF-8" 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. ------=_Part_5164_37121966.1501609847428 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 eve= ry exception.

Example:

try {
=C2=A0 =C2=A0 =C2=A0 ...
} catch (exceptionA e) {
=C2=A0 =C2=A0 = =C2=A0// handle expetionA
=C2=A0 =C2=A0 =C2=A0f();
}


} catch (exceptionB 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();
}


} catch (exceptionD e) {
=C2=A0 =C2=A0 =C2=A0// handle excep= tionD
=C2=A0 =C2=A0 =C2=A0g();
}




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 par= ticular catch blocks.


To avoid that= , proposed improvment could be:


try {
=C2=A0 =C2= =A0 =C2=A0 ...
} catch (e= xceptionA, exceptionB, exceptionC) {
=C2=A0 =C2=A0 =C2=A0// handle= exception (does not matter whether exception A, B or C - we have same hand= ling code for them)
=C2=A0 =C2=A0 =C2= =A0f();=
}
}= catch = (except= ionD e)= {
= =C2=A0 =C2=A0 =C2=A0// handle exceptionD<= /span>
=C2=A0 =C2=A0 =C2=A0g();
}




So, here= 9;s a question: why would you have this circumstance? That is, 3 completely= unrelated exception types require the exact same handling code (to the poi= nt where they don't even use the exception object itself), while simult= aneously there is a fourth exception type which requires different handling= code. What could possibly cause such a thing?

Decent use of RAII el= iminates 99% of `catch` statements for the purpose of cleanup. That leaves = behind work based on the specific kind of exception. I could imagine a data= base throwing a transaction failure exception as well as an out of memory e= xception. You need different code to handle those (assuming you want to han= dle OOM at all).

But why would such a database have multiple unrelat= ed transaction failure exception types? Or multiple unrelated memory except= ion types? Generally speaking, we allow users to catch related exceptions i= n the same statement by using inheritance from a common exception type. If = a database had multiple kinds of transaction failures, they should all be d= erived from a root "transaction failure" exception.

So I f= ind the use case to be dubious. Can you provide a more concrete, less hypot= hetical example?

=

With the instance of o= ne of =C2=A0those exceptions:
catch (exceptionA,= exceptionB, exceptionC e) {=
=C2=A0 =C2=A0f(e);
}


That's rather more disconcerting. Yo= u 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 &= 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 https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/deaedeb0-a699-49e9-826a-c41e674902c0= %40isocpp.org.
------=_Part_5164_37121966.1501609847428-- ------=_Part_5163_2138062996.1501609847427-- .