220 13151 article Path: news.gmane.org!not-for-mail From: abymaroth@googlemail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Try for Object-initialization Date: Fri, 26 Sep 2014 06:09:02 -0700 (PDT) Lines: 67 Approved: news@gmane.org Message-ID: References: <23f86bf6-2f2b-486f-8aef-df6227c25a89@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_58_637317185.1411736942604" X-Trace: ger.gmane.org 1411736950 13863 80.91.229.3 (26 Sep 2014 13:09:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 26 Sep 2014 13:09:10 +0000 (UTC) Cc: abymaroth@googlemail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDQ2HAXQ5ILRB36KSWQQKGQE3OAY2MA@isocpp.org Fri Sep 26 15:09:05 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vc0-f200.google.com ([209.85.220.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XXVGj-0007xK-2g for gclcip-std-proposals@m.gmane.org; Fri, 26 Sep 2014 15:09:05 +0200 Original-Received: by mail-vc0-f200.google.com with SMTP id ij19sf3179333vcb.7 for ; Fri, 26 Sep 2014 06:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; 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:content-type; bh=sLjD7vTfurKtqkTmrnNHb9xirf0J3D5Ws7gvPb7/GSw=; b=PJbdSF+P1TE40Ey8a/OvKvx+iTJANG/chtBeaOCD82hD7QDHuipLNLtVwElMLRFiY+ 1z9myBB+a3uQi2x3MgFIRcrdTF8A0fDDasjGMXN0eqosUeVdmLE1cIg3ryE370i75KgK Du4ke9OhMvjMXAWhlZrm4cQqkUVW5k49SS5kMZRJYbIjZ9hdVRoRcxtWQN6+sj8DkMEI pGy9VXNqWb/swIZYxLV//EADgLhzWBfLBkHQf7CYBFCoFAGTZrgguiVaVuUbib6vtjdU JIr30R6o+XYcWh22siBRfww7UsuJ0XdlxBK+zsmCTA6D5+0/N9nZQ8+AgJDFuZeaEXbk 2+cg== 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:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=sLjD7vTfurKtqkTmrnNHb9xirf0J3D5Ws7gvPb7/GSw=; b=PmLzvcmH2gSnAT4dtFJefXi5aPFQoqagC8M7LidS6AGLlzWLd05qOwbIK1gNMk1MAs qlovGRGkWn1/Fo+uB2/jKYuuJiorXJ2dQbhE9db3CLaVL3/1+gQngfczbJFyUDTVnnzD 8vMbMLx0zFVQHvF1rCV5jMxciu6eVTSF2TPHghWgt6/+k94+Us3Wz7/+E8rcISjHJlUZ OQbV82kNHmuvNKMcR1Sg49IonaKwPDMaKwoE5H244lVWn+FoNrymmRsWySlhgD1Gbpj9 YUrBTYBr4sAn/MwOpvumZDlNCuiG7tH24alh3+L6HTrBJY2+N2M7S7nNBPcIx91+T3QP BOdA== X-Gm-Message-State: ALoCoQnX5s0dWUZXb3bnkSH+dET3S51s7oFohy4bjfjHmCFsY/7piHyEjo7uPBS3fikaruZrFIz5 X-Received: by 10.224.65.66 with SMTP id h2mr17318500qai.5.1411736943758; Fri, 26 Sep 2014 06:09:03 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.48.35 with SMTP id n32ls1189056qga.25.gmail; Fri, 26 Sep 2014 06:09:03 -0700 (PDT) X-Received: by 10.140.34.208 with SMTP id l74mr166875qgl.1.1411736943064; Fri, 26 Sep 2014 06:09:03 -0700 (PDT) In-Reply-To: X-Original-Sender: abymaroth@googlemail.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:13151 Archived-At: ------=_Part_58_637317185.1411736942604 Content-Type: text/plain; charset=UTF-8 A large try-block is not about code length but about the amount of operations that happen inside them. You put the whole application into a single try-block. That's the problem. Of course I can use a try inside the outer try to explicitely catch exceptions from the loop. But consider that this pattern also can be used inside another function and there I don't want to catch loop-exceptions. Nested try-blocks won't work at all for object initializations because they will also bound the object lifetime to the nested scopes. Different exceptions may be a possibility but why I have to design exceptions for all objects? That makes no sense and the exception type should not be related to the object but to the kind of error. But thanks for you response. -- --- 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/. ------=_Part_58_637317185.1411736942604 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A large try-block is not about code length but a= bout the amount of operations that happen inside them. You put the whole ap= plication into a single try-block. That's the problem. Of course I can use = a try inside the outer try to explicitely catch exceptions from the loop. B= ut consider that this pattern also can be used inside another function and = there I don't want to catch loop-exceptions.
 
Nested try-blocks won't work at all for object initializations because= they will also bound the object lifetime to the nested scopes.
 
Different exceptions may be a possibility but why I have to design exc= eptions for all objects? That makes no sense and the exception type should = not be related to the object but to the kind of error.
 
 
But thanks for you response.

--

---
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_58_637317185.1411736942604-- .