From 2688253352275332618
X-Google-Thread: f78e5,82cd3599ce330676
X-Google-NewGroupId: yes
X-Google-Attributes: gid7894ca11fe,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: g2news1.google.com!news4.google.com!news2.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!news.giganews.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 02 Apr 2010 11:40:08 -0500
Return-Path: <cppmods@ruralroute.cs.rpi.edu>
To: (Usenet)
From: Herb Sutter <herb.sutter@gmail.com>
Newsgroups: comp.std.c++
Subject: Re: throwing in a noexcept(true) function
Organization: Forte Inc.  http://www.forteinc.com/apn/
Sender: cppmods@cs.rpi.edu
Approved: austern@google.com
Message-ID: <nu6br51mp2drf4l4bv6t7hinu8dvuoli2n@4ax.com>
References: <4BB4D8B0.3070603@f2.dion.ne.jp>
Content-Type: text/plain; charset=us-ascii
X-Original-Date: Fri, 02 Apr 2010 00:29:42 -0700
X-Submission-Address: std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
Date: Fri,  2 Apr 2010 11:37:55 CST
Lines: 46
X-Usenet-Provider: http://www.giganews.com
X-Trace: sv3-13uNz0+s/NmuCsHZWM2FgGga1XVWjlE+u34M+3hypaIjvaZ7FR/ooNtjRILYN48xZyA/PsDbC4V5ywV!cJiagnrc3Tla/EvL6q3kdiCoYsupAlzZ90aPdp9g4RXaBKyNxDU0XNJxkUb0/11f39vAV1TX
X-Complaints-To: abuse@giganews.com
X-DMCA-Notifications: http://www.giganews.com/info/dmca.html
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
Xref: g2news1.google.com comp.std.c++:2363

On Fri,  2 Apr 2010 00:06:38 CST, Kazutoshi Satoda
<k_satoda@f2.dion.ne.jp> wrote:
>To summarize, the main two points of view that were expressed were
>>> that that trying to propagate an exception out of a noexcept function
>>> should result in:
>>> a) All bets off: Undefined behavior [...]
>>> b) Termination: [...]
>>> The committee has currently penciled in (b).
>>>
>> Another choice that was suggested by some members of the BSI C++ Panel
is:
>> c) implementation-defined behaviour
>>
>
>How about static checking?
>
>d) Render them ill-formed if possible (and terminate if not)

It looks like you posted this *just* after April 1 was over. :-)

But to give a serious answer, since the above is a frequently asked
question: The trouble with (d) is that then you get all the problems
Java gets with statically checked exceptions, such as that that scheme
doesn't work at all with templates (what exactly would you write?) and
even when it does work more often than not quickly devolves into the
meaningless "throw(exception)". As often as I hear a C++ programmer
wish their exception specifications had Java's static semantics, I
hear a Java programmer wish theirs had non-static semantics.

Herb


---
Herb Sutter   (herbsutter.wordpress.com)   (www.gotw.ca)

Convener, SC22/WG21 (C++)                  (www.gotw.ca/iso)
Architect, Visual C++                      (www.gotw.ca/microsoft)

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]



