Exception Specification Compromise
in [C++]
|
From: Goran on 12 Feb 2010 05:41 On Feb 12, 3:03 am, DeMarcus <use_my_alias_h...(a)hotmail.com> wrote: > > I think that you misunderstood this, and I think that's because you > > fail (or refuse?) to accept what throw() does. By writing throw(), I > > am NOT saying "this does not throw". I am saying "if this throws, I > > die". That's a BIG difference. > > No, I don't refuse to accept anything, I'm not that childish. It's just > that I maybe haven't understood what the throw keyword is used for. Well... What throw() does - it's not that hard to look up, or try (I did both when this thread started). What throw() does has also been mentioned in this thread. I thought you should have understood that by now. > It > seems that people use it to get a core dump that will be easier to > debug. Pretty much like an assert() for exceptions. Have I got that > correctly? Not entirely. assert() is out in non-debug builds. IIRC, a throw from throw() function results in unexpected() -> (by default) terminate() - > abort -> (on __some__ implementations/systems) a core dump. > > So your argument is a poor way to turn things around. Because, with > > throw(), if thing throws, you die. Without throw() (and surrounding > > code is not exception-safe), you have a serious bug. Either way, you > > have a bug. But former case, with throw(), is actually much more > > drastic - you die right away. > > I guess a quick death with a core dump would be easier to debug than a > bug that just puts inconsistency in your system. So just swallowing > exceptions with try/catch(...) in a throw()-function may not be the > solution to provide true no-throw guarantee. I prefer a quick death, too. Did I say otherwise? I merely argued that your "Chapter 11" logic is flawed (and, by extension, that book is right about throw). Goran. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nevin :-] Liber on 12 Feb 2010 10:39 In article <6bb964cd-04bb-49b0-b344-a17a2e943209(a)b7g2000yqd.googlegroups.com>, ThosRTanner <ttanner2(a)bloomberg.net> wrote: > On Feb 12,> It's easy to do static checking of throw specifications at compile > time because the compiler knows the throw spec of all the called > functions, because it has to see the prototype before it can compile > the call. Again, I just don't see how you can analyze this without whole program analysis, which isn't trivial. GIven the following: struct Foo { virtual void Bar() const = 0; }; bool DoIThrow(Foo const& f) { try { f.Bar(); return false; } catch (...) { return true; } } So, what does DoIThrow() return: true or false? Personally, I don't know how to do the analysis w/o looking at *every* derived class of DoIThrow. What is your "easy" way to figure this out? And this is still a fairly simple case... -- Nevin ":-)" Liber <mailto:nevin(a)eviloverlord.com> 773 961-1620 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: peter koch larsen on 13 Feb 2010 06:21 On 13 Feb., 04:39, "Nevin :-] Liber" <ne...(a)eviloverlord.com> wrote: > In article > <6bb964cd-04bb-49b0-b344-a17a2e943...(a)b7g2000yqd.googlegroups.com>, > ThosRTanner <ttann...(a)bloomberg.net> wrote: > > > On Feb 12,> It's easy to do static checking of throw specifications at compile > > time because the compiler knows the throw spec of all the called > > functions, because it has to see the prototype before it can compile > > the call. > > Again, I just don't see how you can analyze this without whole program > analysis, which isn't trivial. > > GIven the following: > > struct Foo > { > virtual void Bar() const = 0; > > }; > > bool DoIThrow(Foo const& f) > { > try { f.Bar(); return false; } > catch (...) { return true; } > > } > > So, what does DoIThrow() return: true or false? > > Personally, I don't know how to do the analysis w/o looking at *every* > derived class of DoIThrow. What is your "easy" way to figure this out? > > And this is still a fairly simple case... I can't respond for ThosRTanner, but my understanding is many here simply want a signature on a function, "nothrow", that as an effect forbids throwing an exception or calling a function that might throw. So effectively only nothrow functions can be called outside a try- catch block. The effect would be, of course, that in most interesting cases the function-body would effectively look like: { try { do_something } catch (...) { exit(); } } instead of the simpler { do_something } of a function with a throw() specifier. /Peter -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: DeMarcus on 13 Feb 2010 06:24 Goran wrote: > On Feb 12, 3:03 am, DeMarcus <use_my_alias_h...(a)hotmail.com> wrote: >>> I think that you misunderstood this, and I think that's because you >>> fail (or refuse?) to accept what throw() does. By writing throw(), I >>> am NOT saying "this does not throw". I am saying "if this throws, I >>> die". That's a BIG difference. >> No, I don't refuse to accept anything, I'm not that childish. It's just >> that I maybe haven't understood what the throw keyword is used for. > > Well... What throw() does - it's not that hard to look up, or try (I > did both when this thread started). What throw() does has also been > mentioned in this thread. I thought you should have understood that by > now. > I do know what throw() does. But it's a big difference between what it does and how it's used (or what it represents). Take the operator >> for instance that can be used in at least three different ways depending on if your are working with bit operations, std::cin or boost::spirit. I realized that throw() has apparently never been used to denote no-throw according to D. Abrahams' no-throw guarantee. >> I guess a quick death with a core dump would be easier to debug than a >> bug that just puts inconsistency in your system. So just swallowing >> exceptions with try/catch(...) in a throw()-function may not be the >> solution to provide true no-throw guarantee. > > I prefer a quick death, too. Did I say otherwise? I merely argued that > your "Chapter 11" logic is flawed (and, by extension, that book is > right about throw). > Actually I didn't comment your answer but rather examined my own ideas. > Goran. > > -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Thomas Richter on 14 Feb 2010 08:32
Goran wrote: >> So we have many ways to "finish" a function: >> >> (a) to return normally (without throwing) >> (b) to throw an exception >> (c) to terminate the program (by exit, abort, or exec family) >> (d) to keep going without ever finishing (e.g. by an infinite loop) >> >> and throw() guarantees only that (b) will not happen. > > I think that you just perverted the course of justice ;-). > > What I wrote up there is (what I think is) the purpose of throw(): > it's merely a way to specify that an exception from a particular > function is so unexpected that program should die. Of course, standard > offers options, but if you go with a, d, you are perverting throw(); > options should only be used to... ahem... "enhance" on default > behavior, not significantly change it. IOW, a and d are a case of > "just because you can, doesn't mean you should". That is, of course, the way "throw()" does work according to the standard, but is this actually useful? Because, at the time the program threw where it shouldn't, it is already too late to fix the problem, and while keeping the program crashing instead of continuing in a inconsistent state, it would be *even better* if the compiler would be able to figure such cases out at compile time, and not only at run time, to avoid the problem in first case. It would be beneficial if the compiler could help to detect such cases by a code analysis in the same way a compiler can help to detect modification of "const" objects. Again, this is *not* what throw() does, but it would be definitely a beneficial feature of a compiler. Greetings, Thomas -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |