Exception Specification Compromise
in [C++]
|
From: Bart van Ingen Schenau on 11 Feb 2010 02:15 On Feb 11, 2:17 am, DeMarcus <use_my_alias_h...(a)hotmail.com> wrote: > > I bought the book Exceptional C++ by Herb Sutter. It's an excellent > book, buy it. However, even Sutter himself seems to be totally paralyzed > when it comes to exception specifications, as I found when I > surprisingly read the following. > > "Writing throw() limits you in the future in case you want to change the > underlying implementation to a form that could throw.", page 54. > > Now, anyone in this community, raise a hand if you would be happy if one > of your programmers or colleagues suddenly started to throw from a > no-throw function. It's a silent and efficient way to put a company in > Chapter 11. That depends entirely on the reason why the function had gotten the throw() specification in the first place. If the function was marked as not throwing because that was a side- effect of the original implementation, then that is where an error was made and I would be happy if someone removed the throw() specification and started throwing exceptions. This under the provision that a thorough investigation is done to ensure the calling code does not incorrectly rely on the function not throwing. If the function was marked as not throwing because that is a fundamental premisse of the function, then any exception thrown form such a function would be marked as an error by me. Bart v Ingen Schenau -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: DeMarcus on 11 Feb 2010 09:04 I top post here since Francis Glassborow pointed out WG21; a solution on a higher level. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2855.html However, I will continue answer to this thread. See below. Andreas Wallner wrote: > A few posts ago you described how you would use your proposed warning > for your own code. You would have to sort out a huge mass of warnings > related to librarys using exception specifications. You could not run > those compilations as part of a regression test. I think that you > would most likely overlook some issues although you checked for > issued, just because of the huge amount of repetitive work the > programmer checking the compiler output would have to do. > > >> void f() throw() >> { >> try { myVector.pop_back(); } catch(...) {} >> } > > That could for, but what if you accidentially wrap something in such a > try-catch block that is not-nothrow? I would consider it really bad if > that happened... > I just realized that the keyword throw has been used as a kind of assert() for exceptions. In that case my whole idea fails. However, I was proposing the idea of using throw() indicating no-throw similar to noexcept in WG21 but without having to change the standard. > Also I wouldn't use throw() because of the additional code that is > generated and does not help me in any way. > >> That is why I proposed it as an optional feature so that it won't affect >> nobody except those who see it as a help. As for me, until this no-throw >> issue has gotten a clean solution, I prefer this clutter code to a core >> dump. > > If you are sure that the function you wrapped with your try-catch > block is really nothrow, you would never have to fear a core dump. If > you are not sure that the function is nothrow then you would swallow > the thrown exception, and have ignored it... I would feel better with > an application that catches this exception at an much higher level, > then just swallow the exception and never have a clue that it was > thrown. > Nothrow is an important part of D. Abrahams' exception safety guarantee. My idea was to let the compiler help you conform to that guarantee, however, I realize that WG21 is needed to not give throw() double meanings. > I think such a warning would introduce more problems then it would > solve. You would write code that has no functional use, that is only > there to be able to do checks with that specific compiler warning (you > would anyway have to check by hand). > >> Now, anyone in this community, raise a hand if you would be happy if one >> of your programmers or colleagues suddenly started to throw from a >> no-throw function. It's a silent and efficient way to put a company in >> Chapter 11. > > It would be better to say that you should only use throw() (if you use > it at all) if you had to, but not if you could (depending on the > current implementation). > > I think that solid test cases for your own stuff, as well as code > reviews would be a better approach to this problem. Or try to write a > static code analysis tool that can do this, like some others already > suggested. But without parsing library code as well such a tool might > not be usable at all. (Because of the above mentioned problems) > Yes, the idea I proposed was a static tool. My mistake was that I thought we could use throw() to tag no-throw functions since nobody uses exception specifications anyway. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: DeMarcus on 11 Feb 2010 09:04 I top post here since Francis Glassborow pointed out WG21; a solution on a higher level. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2855.html However, I will continue answer to this thread. See below. Bart van Ingen Schenau wrote: > On Feb 11, 2:17 am, DeMarcus <use_my_alias_h...(a)hotmail.com> wrote: >> I bought the book Exceptional C++ by Herb Sutter. It's an excellent >> book, buy it. However, even Sutter himself seems to be totally paralyzed >> when it comes to exception specifications, as I found when I >> surprisingly read the following. >> >> "Writing throw() limits you in the future in case you want to change the >> underlying implementation to a form that could throw.", page 54. >> >> Now, anyone in this community, raise a hand if you would be happy if one >> of your programmers or colleagues suddenly started to throw from a >> no-throw function. It's a silent and efficient way to put a company in >> Chapter 11. > > That depends entirely on the reason why the function had gotten the > throw() specification in the first place. > If the function was marked as not throwing because that was a side- > effect of the original implementation, then that is where an error was > made and I would be happy if someone removed the throw() specification > and started throwing exceptions. This under the provision that a > thorough investigation is done to ensure the calling code does not > incorrectly rely on the function not throwing. > During this thread I have realized that throw() has never been used the no-throw way D. Abrahams published. For a huge project, a thorough investigation may be expensive but not impossible. However, what may be impossible is to change all the places relying on the function being no-throw (Abrahams' way). Today this no-throw issue is a problem for at least three reasons. * It's stressful to do a thorough no-throw investigation since the compiler won't help you. * It's way too easy to accidentally throw from a no-throw function without any warning from the compiler. * Since the compiler doesn't warn you, design flaws can easy slip through and survive until a refactoring would cost as much as rewriting the whole application. > If the function was marked as not throwing because that is a > fundamental premisse of the function, then any exception thrown form > such a function would be marked as an error by me. > > Bart v Ingen Schenau > > -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: DeMarcus on 11 Feb 2010 09:05 I top post here since Francis Glassborow pointed out WG21; a solution on a higher level. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2855.html However, I will continue answer to this thread. See below. Seungbeom Kim wrote: > DeMarcus wrote: >> >> I bought the book Exceptional C++ by Herb Sutter. It's an excellent >> book, buy it. However, even Sutter himself seems to be totally paralyzed >> when it comes to exception specifications, as I found when I >> surprisingly read the following. >> >> "Writing throw() limits you in the future in case you want to change the >> underlying implementation to a form that could throw.", page 54. >> >> Now, anyone in this community, raise a hand if you would be happy if one >> of your programmers or colleagues suddenly started to throw from a >> no-throw function. It's a silent and efficient way to put a company in >> Chapter 11. > > Only if you relied on the fact that the function did not throw. > And you don't usually want to do that except for a few specific > functions advertised and well-known as non-throwing, such as > destructors, pop_back(), erase(), swap(), and so on. And some of > them (especially templates) depend on other functions not throwing, > so throw() can not be applied uniformly. > I agree with your message but not with what you are saying. You say "well-known as non-throwing". That's error prone knowledge! Let the compiler keep track of that for you. > So, the general rule is to assume that most functions can throw, > and program defensively. Fortunately, with proper techniques such > as RAII, the additional burden can be made minimal. > -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: DeMarcus on 11 Feb 2010 09:03
I top post here since Francis Glassborow pointed out WG21; a solution on a higher level. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2855.html However, I will continue answer to this thread. See below. Goran wrote: > On Feb 11, 2:17 am, DeMarcus <use_my_alias_h...(a)hotmail.com> wrote: >> "Writing throw() limits you in the future in case you want to change the >> underlying implementation to a form that could throw.", page 54. >> >> Now, anyone in this community, raise a hand if you would be happy if one >> of your programmers or colleagues suddenly started to throw from a >> no-throw function. It's a silent and efficient way to put a company in >> Chapter 11. > > 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. 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? I've got the impression that nobody uses exception specifications, therefore I thought it would be a great idea to use throw() to tell an optional compiler feature that this function does not throw. However, WG21 seems to be what I actually was looking for; a way to have the compiler find incorrect no-throw functions. > 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. > So if absence of throw() in an otherwise no-throw function puts > company in Chapter 11, then it's presence can only put it there > faster. > > Goran. > > -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |