C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Tool to verify throw specifications, unexpected exceptions? Goto page 1, 2, 3  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message Aaron W. LaFramboise Guest Posted: Mon Dec 08, 2003 11:02 pm    Post subject: Tool to verify throw specifications, unexpected exceptions? Hi, Is there a tool freely availible that I might use to check my program for cases where a function may throw exceptions not allowed by its exception specification? I realize that there are many problems with this sort of thing in C++; yet I beleive that some sort of tool like this is needed to responsibly write code that extensively uses exception specifications. In particular, with the advent of compilers implementing zero-cost exceptions, I might be willing to accept Java-style strict exception specification checking. Aaron W. LaFramboise [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alan Griffiths Guest Posted: Tue Dec 09, 2003 5:11 pm    Post subject: Re: Tool to verify throw specifications, unexpected exceptio "Aaron W. LaFramboise" <aaronblue6 (AT) cox-internet (DOT) com> wrote Quote: Hi, Is there a tool freely availible that I might use to check my program for cases where a function may throw exceptions not allowed by its exception specification? No, but there was an article discussing the design of sucha tool in Overload recently. Quote: I realize that there are many problems with this sort of thing in C++; yet I beleive that some sort of tool like this is needed to responsibly write code that extensively uses exception specifications. With exceptions specifications as currently defined it is, IMO, irresponsible to write code that that extensively uses exception specifications. (A tool might mitigate the risks, but why take them?) Quote: In particular, with the advent of compilers implementing zero-cost exceptions, I might be willing to accept Java-style strict exception specification checking. Java style isn't as strict as you might believe. (Unexpected *checked* exceptions can propagate at runtime - and unchecked exceptions bypass the compile time checks.) The Java model is an interesting experiment and a novel design context. But not one to be repeated! (If anything it is more broken than the C++ model.) -- Alan Griffiths http://www.octopull.demon.co.uk/ [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Ben Hutchings Guest Posted: Tue Dec 09, 2003 8:10 pm    Post subject: Re: Tool to verify throw specifications, unexpected exceptio Aaron W. LaFramboise wrote: Quote: Hi, Is there a tool freely availible that I might use to check my program for cases where a function may throw exceptions not allowed by its exception specification? I realize that there are many problems with this sort of thing in C++; yet I beleive that some sort of tool like this is needed to responsibly write code that extensively uses exception specifications. In particular, with the advent of compilers implementing zero-cost exceptions, I might be willing to accept Java-style strict exception specification checking. A function template or member function of a class template cannot in general provide an exception specification, as the set of exceptions it may be dependent on the template parameters and cannot automatically be derived from them. So any C++ code that calls such functions cannot have a statically verifiable exception specification either. Given the use of templates in the standard library, and the rather limited exception specifications even on non-template functions, it would be very difficult to write useful exception specifications on more than a fraction of the code in a program that uses the standard library much. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Abrahams Guest Posted: Tue Dec 09, 2003 10:06 pm    Post subject: Re: Tool to verify throw specifications, unexpected exceptio [email]devnull (AT) octopull (DOT) demon.co.uk[/email] (Alan Griffiths) writes: Quote: Is there a tool freely availible that I might use to check my program for cases where a function may throw exceptions not allowed by its exception specification? No, but there was an article discussing the design of sucha tool in Overload recently. Actually, I think QA C++ might do that. See http://www.programmingresearch.com/QACPP_LINK.htm for details. -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Roland Pibinger Guest Posted: Thu Dec 11, 2003 11:44 am    Post subject: Re: Tool to verify throw specifications, unexpected exceptio On 9 Dec 2003 12:11:12 -0500, [email]devnull (AT) octopull (DOT) demon.co.uk[/email] (Alan Griffiths) wrote: Quote: "Aaron W. LaFramboise" <aaronblue6 (AT) cox-internet (DOT) com> wrote Hi, I realize that there are many problems with this sort of thing in C++; yet I beleive that some sort of tool like this is needed to responsibly write code that extensively uses exception specifications. With exceptions specifications as currently defined it is, IMO, irresponsible to write code that that extensively uses exception specifications. (A tool might mitigate the risks, but why take them?) This is a common opinion among (some) C++ gurus (see eg. Herb Sutter's verdict against exception specifications) but IMO it should not be the final judgement. Being able to specify exceptions in code as part of the contract between caller and supplier really is an important feature a programming language. In C++ if you cannot determine all possible exceptions thrown within a function just add std::bad_exception to the exception specification. Quote: In particular, with the advent of compilers implementing zero-cost exceptions, I might be willing to accept Java-style strict exception specification checking. Java style isn't as strict as you might believe. (Unexpected *checked* exceptions can propagate at runtime - and unchecked exceptions bypass the compile time checks.) What is an unexpected checked exception in Java? Quote: The Java model is an interesting experiment and a novel design context. But not one to be repeated! (If anything it is more broken than the C++ model.) Amazingly the "broken" Java model works very well in practice once you have cought some basic rules. Best regards, Roland Pibinger [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Alan Griffiths Guest Posted: Thu Dec 11, 2003 9:27 pm    Post subject: Re: Tool to verify throw specifications, unexpected exceptio [email]rpbg123 (AT) yahoo (DOT) com[/email] (Roland Pibinger) wrote in message news:<3fd77df3.1752754 (AT) news (DOT) utanet.at>... Quote: On 9 Dec 2003 12:11:12 -0500, [email]devnull (AT) octopull (DOT) demon.co.uk[/email] (Alan Griffiths) wrote: With exceptions specifications as currently defined it is, IMO, irresponsible to write code that that extensively uses exception specifications. (A tool might mitigate the risks, but why take them?) This is a common opinion among (some) C++ gurus (see eg. Herb Sutter's verdict against exception specifications) but IMO it should not be the final judgement. I didn't arrive at this conclusion lightly and, unless I see some good evidence for changing it, I'll stick to it. Quote: Being able to specify exceptions in code as part of the contract between caller and supplier really is an important feature a programming language. That is an admirable ideal and a language in which it is achieved would be an interesting design context. I'd like to try it. But this hypothetical language isn't C++ (or Java), and without practical experience of such an capability, we don't know if it works. I'd like to see a proposal to allow this (and other DBC support) in C++. But, currently, I have more urgent concerns and it isn't something I have the time to address. Quote: In C++ if you cannot determine all possible exceptions thrown within a function just add std::bad_exception to the exception specification. In C++ if you cannot (or don't care to) determine all possible exceptions that might propagate from a function just don't write an exception specification. Your suggested approach forces the compiler to generate code whose sole effect is to throw away any contextual information "bad" exceptions contain. Quote: Java style isn't as strict as you might believe. (Unexpected *checked* exceptions can propagate at runtime - and unchecked exceptions bypass the compile time checks.) What is an unexpected checked exception in Java? One that propagates from a function whose throw specification doesn't include it: "Did you know that any Java method can throw arbitrary checked exceptions without declaring them?" http://www.javaworld.com/javaworld/javaqa/2003-02/02-qa-0228-evilthrow.html Quote: Amazingly the "broken" Java model works very well in practice once you have cought some basic rules. That is a debate for another forum: "Does Java need Checked Exceptions?" http://www.mindview.net/Etc/Discussions/CheckedExceptions -- Alan Griffiths http://www.octopull.demon.co.uk/ [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Abrahams Guest Posted: Thu Dec 11, 2003 9:28 pm    Post subject: Re: Tool to verify throw specifications, unexpected exceptio [email]rpbg123 (AT) yahoo (DOT) com[/email] (Roland Pibinger) writes: Quote: On 9 Dec 2003 12:11:12 -0500, [email]devnull (AT) octopull (DOT) demon.co.uk[/email] (Alan Griffiths) wrote: "Aaron W. LaFramboise" <aaronblue6 (AT) cox-internet (DOT) com> wrote Hi, I realize that there are many problems with this sort of thing in C++; yet I beleive that some sort of tool like this is needed to responsibly write code that extensively uses exception specifications. With exceptions specifications as currently defined it is, IMO, irresponsible to write code that that extensively uses exception specifications. (A tool might mitigate the risks, but why take them?) This is a common opinion among (some) C++ gurus (see eg. Herb Sutter's verdict against exception specifications) but IMO it should not be the final judgement. Being able to specify exceptions in code as part of the contract between caller and supplier really is an important feature a programming language. "The ability to specify", by itself, is a fine feature. We have a thing in C++ called a "comment" which provides that, and only that. The biggest problem with C++ exception-specifications is how they deal with broken contracts. Quote: In C++ if you cannot determine all possible exceptions thrown within a function just add std::bad_exception to the exception specification. So you end up with std::bad_exception propagated all over your code? What more does that tell you than having no specification at all? And why should I pay for the executable size bloat and/or slowdown this will cause? -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Philipp Janda Guest Posted: Fri Dec 12, 2003 9:45 am    Post subject: Re: Tool to verify throw specifications, unexpected exceptio Alan Griffiths schrieb: Quote: This is a common opinion among (some) C++ gurus (see eg. Herb Sutter's verdict against exception specifications) but IMO it should not be the final judgement. I didn't arrive at this conclusion lightly and, unless I see some good evidence for changing it, I'll stick to it. I agree with you, that the current C++ exception specifications are not really useful. Quote: Being able to specify exceptions in code as part of the contract between caller and supplier really is an important feature a programming language. That is an admirable ideal and a language in which it is achieved would be an interesting design context. I'd like to try it. But this hypothetical language isn't C++ (or Java), Why not? I think Java is doing pretty well in this regard. There may be some holes yet, but nothing that couldn't be fixed easily. Quote: and without practical experience of such an capability, we don't know if it works. Java style isn't as strict as you might believe. (Unexpected *checked* exceptions can propagate at runtime - and unchecked exceptions bypass the compile time checks.) What is an unexpected checked exception in Java? One that propagates from a function whose throw specification doesn't include it: "Did you know that any Java method can throw arbitrary checked exceptions without declaring them?" http://www.javaworld.com/javaworld/javaqa/2003-02/02-qa-0228-evilthrow.html The article mentions two approaches to achieve this misbehaviour: 1. using the deprecated method Thread.stop... Although I believe that this method was not deprecated because of the exception issue, Sun has recognized that this method can cause problems, it should not be used anymore and will eventually be removed. There were a couple of bugs which showed up right after the code was released, for example Thread.stop could cause deadlocks so this is not the first one. I know that software may contain bugs (surprise!), and I'm satisfied when they get fixed. In this case they are right on their way... 2. using a disassembler and an assembler... Did I read right? I can fool the static type checking of my C++ compiler using a disassembler and an assembler without any problems. Does this mean that we shouldn't have static type checking in C++? You could argue though, that in some sense Sun failed to make their bytecode verifier fool-proof. Quote: Amazingly the "broken" Java model works very well in practice once you have cought some basic rules. That is a debate for another forum: "Does Java need Checked Exceptions?" http://www.mindview.net/Etc/Discussions/CheckedExceptions The author of this article compares Python to C++. IMO, there is not much point doing this since Python and C++ (/Java) are used in different ways. In Python you do things like rapid prototyping, you enter two lines of code and look what it does. Of course, exception specifications (and exception handling) are unsuitable in such a scenario. Python does not have static type checking or private/protected members either. So probably the answer to the question is: no, Java doesn't need checked exceptions or static typing or even Java at all, because we have Python! (I know that some will disagree The last part of the article makes me thinking, though... But coming back to the topic of this thread: using a separate tool would enable those who want to check the exception specifications and exceptions to get warnings etc., and those who don't care (or do rapid prototyping in C++ - oh my goodness) could just forget about them. But with the current C++ exception specifications you cannot even do that without runtime costs. Philipp [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Roland Pibinger Guest Posted: Fri Dec 12, 2003 9:47 am    Post subject: Re: Tool to verify throw specifications, unexpected exceptio On 11 Dec 2003 16:27:38 -0500, [email]devnull (AT) octopull (DOT) demon.co.uk[/email] (Alan Griffiths) wrote: Quote: rpbg123 (AT) yahoo (DOT) com (Roland Pibinger) wrote in message news:<3fd77df3.1752754 (AT) news (DOT) utanet.at>... In C++ if you cannot determine all possible exceptions thrown within a function just add std::bad_exception to the exception specification. In C++ if you cannot (or don't care to) determine all possible exceptions that might propagate from a function just don't write an exception specification. Your suggested approach forces the compiler to generate code whose sole effect is to throw away any contextual information "bad" exceptions contain. std::bad_exception is only thrown if an unexpected exception occures, ie. an exception not anticipated in the exception specification. std::bad_exception is a last resort not a "normal" exceptional case. Quote: Java style isn't as strict as you might believe. (Unexpected *checked* exceptions can propagate at runtime - and unchecked exceptions bypass the compile time checks.) What is an unexpected checked exception in Java? One that propagates from a function whose throw specification doesn't include it: "Did you know that any Java method can throw arbitrary checked exceptions without declaring them?" http://www.javaworld.com/javaworld/javaqa/2003-02/02-qa-0228-evilthrow.html This article describes a hack that has no impact on practical Java programming. Best regards, Roland Pibinger [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Philipp Janda Guest Posted: Fri Dec 12, 2003 9:47 am    Post subject: Re: Tool to verify throw specifications, unexpected exceptio Ben Hutchings schrieb: Quote: A function template or member function of a class template cannot in general provide an exception specification, as the set of exceptions it may be dependent on the template parameters and cannot automatically be derived from them. As soon the template is instantiated all necessary types (and exception specifications) are known to the compiler. This is still at compile time, so static exception testing should be possible. Quote: So any C++ code that calls such functions cannot have a statically verifiable exception specification either. But I admit, that it would be difficult for a separate tool to achieve this testing, since it would probably need all features of a full C++ compiler. Quote: Given the use of templates in the standard library, and the rather limited exception specifications even on non-template functions, it would be very difficult to write useful exception specifications on more than a fraction of the code in a program that uses the standard library much. I agree with that, but I think that the reason is that the current exception specifications are so horribly broken. If exception specifications were useful (and wouldn't cost so much), they would be added to the library implementations in no time. Philipp [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Roland Pibinger Guest Posted: Fri Dec 12, 2003 9:48 am    Post subject: Re: Tool to verify throw specifications, unexpected exceptio On 11 Dec 2003 16:28:08 -0500, David Abrahams <dave (AT) boost-consulting (DOT) com> wrote: Quote: rpbg123 (AT) yahoo (DOT) com (Roland Pibinger) writes: This is a common opinion among (some) C++ gurus (see eg. Herb Sutter's verdict against exception specifications) but IMO it should not be the final judgement. Being able to specify exceptions in code as part of the contract between caller and supplier really is an important feature a programming language. "The ability to specify", by itself, is a fine feature. We have a thing in C++ called a "comment" which provides that, and only that. We could also define all parameters as void* and specify the real types in the comment but I hope you agree that specification in code is better than comment. Quote: The biggest problem with C++ exception-specifications is how they deal with broken contracts. Yes, and the way C++ handles this problem is std::bad_exception. Quote: In C++ if you cannot determine all possible exceptions thrown within a function just add std::bad_exception to the exception specification. So you end up with std::bad_exception propagated all over your code? Either you can determine all thrown exceptions (eg. by surrounding your function-body with a catch (...) or you must add std::bad_exception to the exception specification. Quote: What more does that tell you than having no specification at all? It tells you which exceptions you can expect in exceptional situations and that in a few unexpected cases std::bad_exception might be thrown. Quote: And why should I pay for the executable size bloat and/or slowdown this will cause? IMO, exception specifications are especially important for high level classes/interfaces of components. They are not needed eg. for private member functions. Compared to templates do exception specifications really dramatically increase code size? Best regards, Roland Pibinger [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Francis Glassborow Guest Posted: Fri Dec 12, 2003 6:26 pm    Post subject: Re: Tool to verify throw specifications, unexpected exceptio In article <brb1jn$1anjm$1 (AT) uni-berlin (DOT) de>, Philipp Janda <siffiejoe (AT) gmx (DOT) net> writes Quote: I agree with that, but I think that the reason is that the current exception specifications are so horribly broken. If exception specifications were useful (and wouldn't cost so much), they would be added to the library implementations in no time. In order to make them useful I think: 1) We have to make them compile time checkable (note that the designers of Java seem to believe that this is not, in general, possible) 2) We have to make them usable in the context of templates and, as of yet, I have not seen a proposal which gets even close to addressing this issue. 3) We have to provide a mechanism for suppressing them in release executables (we really do not want program aborting on the customers machine, and given that we also do not want the footprint and performance to be affected by exception specifications.) -- Francis Glassborow ACCU Author of 'You Can Do It!' see http://www.spellen.org/youcandoit or http://www.robinton.demon.co.uk [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Peter Dimov Guest Posted: Sat Dec 13, 2003 2:02 am    Post subject: Re: Tool to verify throw specifications, unexpected exceptio [email]rpbg123 (AT) yahoo (DOT) com[/email] (Roland Pibinger) wrote in message news:<3fd90fed.4144005 (AT) news (DOT) utanet.at>... Quote: On 11 Dec 2003 16:28:08 -0500, David Abrahams [email]dave (AT) boost-consulting (DOT) com[/email]> wrote: [email]rpbg123 (AT) yahoo (DOT) com[/email] (Roland Pibinger) writes: This is a common opinion among (some) C++ gurus (see eg. Herb Sutter's verdict against exception specifications) but IMO it should not be the final judgement. Being able to specify exceptions in code as part of the contract between caller and supplier really is an important feature a programming language. "The ability to specify", by itself, is a fine feature. We have a thing in C++ called a "comment" which provides that, and only that. We could also define all parameters as void* and specify the real types in the comment but I hope you agree that specification in code is better than comment. Proponents of dynamically checked languages will not agree, but that aside, strict type checking is better than a comment because it carries a significant amount of information. For a typical library, the exception specification of most functions is either throw(), throw(std::exception), or throw(whatever operation X of type T throws). If you try to be more precise, you end up with overspecifying implementation details (i.e. "you must always fail with bad_alloc" implies "you must never attempt to allocate a resource other than memory"), forcing the function to discard failure information ("I will just catch(...) and throw bad_alloc, as mandated"), or imposing unnecessary exception translation on intermediate layers. It's much easier to just handle everything at the top level handler and let the intermediate layers be exception neutral. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze@gabi-soft.fr Guest Posted: Sat Dec 13, 2003 2:07 am    Post subject: Re: Tool to verify throw specifications, unexpected exceptio [email]devnull (AT) octopull (DOT) demon.co.uk[/email] (Alan Griffiths) wrote in message news:<8ab0685f.0312110807.77aa73c7 (AT) posting (DOT) google.com>... Quote: rpbg123 (AT) yahoo (DOT) com (Roland Pibinger) wrote in message news:<3fd77df3.1752754 (AT) news (DOT) utanet.at>... On 9 Dec 2003 12:11:12 -0500, [email]devnull (AT) octopull (DOT) demon.co.uk[/email] (Alan Griffiths) wrote: With exceptions specifications as currently defined it is, IMO, irresponsible to write code that that extensively uses exception specifications. (A tool might mitigate the risks, but why take them?) This is a common opinion among (some) C++ gurus (see eg. Herb Sutter's verdict against exception specifications) but IMO it should not be the final judgement. I didn't arrive at this conclusion lightly and, unless I see some good evidence for changing it, I'll stick to it. Being able to specify exceptions in code as part of the contract between caller and supplier really is an important feature a programming language. That is an admirable ideal and a language in which it is achieved would be an interesting design context. I'd like to try it. But this hypothetical language isn't C++ (or Java), and without practical experience of such an capability, we don't know if it works. Such languages do exist. (Modula-3, for example.) The people I know who have used them seem to have rather positive opinions about this feature. But I must admit that it is a limited sample (and I believe that there has been a move in the Modula-3 community, small as it is, to introduce unchecked exceptions for certain things, like insufficient memory). I think that part of the problem depends on just what kind of errors you want to be able to recover from -- in most applications, it is a rare function at the application level which cannot raise bad_alloc, and having to repeat this in *every* function declaration is a pain. I think to gain acceptance and still be useful, some sort of mechanism is needed to be able to specify a general default (e.g. std::bad_alloc), with an exception specification which either adds or removes exceptions (since you also need functions guaranteed not to throw, not even bad_alloc). In addition to some way of declaring what a template function can throw according to the type it is instantiated over. For the moment, I know of no reasonable syntax for either. And as much as I'd like some sort of static verification, until someone proposes a reasonable syntax, there's no point in arguing the question. -- James Kanze GABI Software mailto:kanze (AT) gabi-soft (DOT) fr Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top David Abrahams Guest Posted: Sat Dec 13, 2003 2:08 am    Post subject: Re: Tool to verify throw specifications, unexpected exceptio [email]rpbg123 (AT) yahoo (DOT) com[/email] (Roland Pibinger) writes: Quote: On 11 Dec 2003 16:28:08 -0500, David Abrahams [email]dave (AT) boost-consulting (DOT) com[/email]> wrote: [email]rpbg123 (AT) yahoo (DOT) com[/email] (Roland Pibinger) writes: This is a common opinion among (some) C++ gurus (see eg. Herb Sutter's verdict against exception specifications) but IMO it should not be the final judgement. Being able to specify exceptions in code as part of the contract between caller and supplier really is an important feature a programming language. "The ability to specify", by itself, is a fine feature. We have a thing in C++ called a "comment" which provides that, and only that. We could also define all parameters as void* and specify the real types in the comment but I hope you agree that specification in code is better than comment. Not neccessarily. If our argument types were only checked at runtime and caused termination when the checks failed AND (this is the clincher) most of the time when a check failed it was actually possible for the program to proceed anyway, you'd have a situation comparable to C++ exception-specifications. A C++ argument type declaration says something immediate about the types of parameters the function can handle. If you violate it without static checking, you can be almost certain something would go wrong. An exception-specification purports to say something about what the entire call chain leading up to the called function must be able to handle. The problem is that most functions written with exception-handling in mind handle all exceptions equally well, by simply allowing them to pass through. Some jobs are actually handled better with a fully dynamic type system than with a static checking. One nice thing about dynamic typing is that it can reduce coupling. That's one reason that languages like LISP and Python are popular (no, Python is not just for quick hacks; I read your other post - people build real systems in Python). C++ exceptions essentially have a dynamic type system and not a static one. I think this is appropriate, because the alternative is a high degree of wasted coupling required to link up all the exception specifications of inner functions with the places exceptions are handled. Quote: The biggest problem with C++ exception-specifications is how they deal with broken contracts. Yes, and the way C++ handles this problem is std::bad_exception. That's not handling it. In fact, that's just masking it. You lose all information about the real problem. Quote: In C++ if you cannot determine all possible exceptions thrown within a function just add std::bad_exception to the exception specification. So you end up with std::bad_exception propagated all over your code? Either you can determine all thrown exceptions (eg. by surrounding your function-body with a catch (...) or you must add std::bad_exception to the exception specification. What more does that tell you than having no specification at all? It tells you which exceptions you can expect in exceptional situations and that in a few unexpected cases std::bad_exception might be thrown. A comment can do that just as well. Better, in fact, because it has none of the downsides of exception-specifications. Quote: And why should I pay for the executable size bloat and/or slowdown this will cause? IMO, exception specifications are especially important for high level classes/interfaces of components. Why? Quote: They are not needed eg. for private member functions. If you use them some places but you don't use them everywhere you're likely to generate even more wasted code. Quote: Compared to templates do exception specifications really dramatically increase code size? Yes, really. There's no comparison. Templates, by themselves, don't increase code size at all. See http://tinyurl.com/yxj9 and http://tinyurl.com/yxjh Exception-specifications *can* be used to decrease code size on some compilers, if used consistently and with extreme care. Mostly you have to stick to simple "throw()". -- Dave Abrahams Boost Consulting www.boost-consulting.com [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         C++Talk.NET Forum Index -> C++ Language (Moderated) All times are GMT Goto page 1, 2, 3  Next Page 1 of 3   Jump to: Select a forum C/C++----------------C LanguageC Language (Moderated)C++ Language (Moderated)C++ language (comp.lang.c++)C++ language, library and standards Non-English C/C++ Newsgroups----------------C++ (German)C++ (French)  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.