C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  wisdom of throw() declarations Goto page 1, 2, 3  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message ICE Guest Posted: Thu Nov 03, 2005 10:54 am    Post subject: wisdom of throw() declarations Hi! I've been looking for best practise regarding the use of throw() declarations and have been confronted with many different (and seemingly irreconcilable) points of view. In brief summary could be: 1) throw() declarations should be used extensively as it helps read/predict a program's behaviour 2) throw() declarations should not be used, or used as little as possible, to avoid portability issues and unexpected compiler behaviour 3) throw() declarations should be avoided with inline'd functions, but are ok otherwise I would appreciate further opinions/insight into these issues... Thanks. -- -- ICE -- [ 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 Nov 03, 2005 11:22 pm    Post subject: Re: wisdom of throw() declarations "ICE" <pisoi (AT) hispeed (DOT) ch> writes: Quote: Hi! I've been looking for best practise regarding the use of throw() declarations and have been confronted with many different (and seemingly irreconcilable) points of view. In brief summary could be: 1) throw() declarations should be used extensively as it helps read/predict a program's behaviour 2) throw() declarations should not be used, or used as little as possible, to avoid portability issues and unexpected compiler behaviour 3) throw() declarations should be avoided with inline'd functions, but are ok otherwise I would appreciate further opinions/insight into these issues... All of those rules are too simplistic. The main advantage of 1) is that it can help to optimize a program's size, and sometimes its speed (http://groups.google.com/group/comp.lang.c++.moderated/msg/74e29c6c0054f9d3?hl=en&) I don't think 2) makes much sense. There *is* a popular compiler (MSVC) that will not call unexpected() when it should. However, unless you're using exception specifications for exception translation (impossible when the exception specification is empty), the violation of such a specification essentially means the program is broken. In that case, calling terminate() is usually no better than simply propagating the exception. There's nothing wrong with empty exception specifications on inline function as long as rule 1) is being followed. The main reason to avoid empty exception specifications is that people don't follow rule 1). In other words, the functions you're calling probably don't all have empty exception specifications. That means a conforming compiler has to generate, essentially, a try/catch block around each such function call. That said, since MSVC ignores exception specifications except as an optimization guide, if you're using that compiler it won't generate those try/catch. So in the end it comes down to your compiler's EH implementation, your needs in terms of speed/space, and your ability to impose the throw() discipline in all the code you write Sorry, but there are no easy answers to this one :) -- 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 Ron Natalie Guest Posted: Thu Nov 03, 2005 11:22 pm    Post subject: Re: wisdom of throw() declarations ICE wrote: Quote: 1) throw() declarations should be used extensively as it helps read/predict a program's behaviour Well it might provide a prediction of the program behavior, but the issue is that the prediction isn't worth much. A throw specification doesn't mean that no exceptions will occur other than the ones specified but rather that the program will be forced to terminate rather than allowing exceptions to pass up from that function. Quote: 2) throw() declarations should not be used, or used as little as possible, to avoid portability issues and unexpected compiler behaviour I don't think t here's any real portability issue. The worst that tends to happen is compilers don't handle them. Quote: 3) throw() declarations should be avoided with inline'd functions, but are ok otherwise Huh? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gene Bushuyev Guest Posted: Fri Nov 04, 2005 10:55 am    Post subject: Re: wisdom of throw() declarations "ICE" <pisoi (AT) hispeed (DOT) ch> wrote Quote: Hi! I've been looking for best practise regarding the use of throw() declarations and have been confronted with many different (and seemingly irreconcilable) points of view. In brief summary could be: 1) throw() declarations should be used extensively as it helps read/predict a program's behaviour 2) throw() declarations should not be used, or used as little as possible, to avoid portability issues and unexpected compiler behaviour 3) throw() declarations should be avoided with inline'd functions, but are ok otherwise I would appreciate further opinions/insight into these issues... Here is a summary of exception specifications (E.S.) pluses and minuses. Whether to use them and when, it's a decision depending on the particular circumstances. 1) E.S. create run-time checks. That means they won't help you at compile time. They document the intent, but at least at compile time that documentation is not better than a comment: both are not detected by compiler, and both can go out of synch. 2) E.S. may (and probably always do) impose run-time penalty and can prevent compiler optimizations. 3) E.S. doesn't guarantee that the code can throw only listed exceptions. Compiler just guarantees that it will shoot them on the spot, probably terminating your program as well. Violation of E.S. causes unexpected() function to be called. You can install your own handler, but you are unlikely to do anything useful with that other than terminating your application. 4) E.S. cannot be typedef-ed, but function pointers can easily be assigned. 5) E.S. participate in function overriding. It's good of course that the base class contract is enforced. But when designing base class, it's rarely possible to know all the exceptions the derived classes should be able to throw. It's easier to foresee what you don't want your derived functions to throw. But there is no such thing as negative E.S. except for throw(). -- Gene Bushuyev ~ Cadence Design Systems [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Paul Floyd Guest Posted: Fri Nov 04, 2005 11:05 am    Post subject: Re: wisdom of throw() declarations On 3 Nov 2005 05:54:07 -0500, ICE <pisoi (AT) hispeed (DOT) ch> wrote: Quote: Hi! I've been looking for best practise regarding the use of throw() declarations and have been confronted with many different (and seemingly irreconcilable) points of view. In brief summary could be: 1) throw() declarations should be used extensively as it helps read/predict a program's behaviour For legibility, comments can achieve this. Quote: 2) throw() declarations should not be used, or used as little as possible, to avoid portability issues and unexpected compiler behaviour 3) throw() declarations should be avoided with inline'd functions, but are ok otherwise See Hutter's Exceptional C++ Style for good coverage of this. Basically he says to never use them. A Bientot Paul -- Paul Floyd http://paulf.free.fr (for what it's worth) Surgery: ennobled Gerald. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Martin Bonner Guest Posted: Fri Nov 04, 2005 11:10 am    Post subject: Re: wisdom of throw() declarations ICE wrote: Quote: Hi! I've been looking for best practise regarding the use of throw() declarations and have been confronted with many different (and seemingly irreconcilable) points of view. I think you need to specify whether you are talking about exception specifications in general (for example "throw(std::exception)" ), or whether you are specifically talking about EMPTY exception specifications ("throw()"). I am pretty sure that Dave Abrahams reply assumed the latter and Ron Natalie the former. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top kanze Guest Posted: Fri Nov 04, 2005 11:12 am    Post subject: Re: wisdom of throw() declarations David Abrahams wrote: Quote: "ICE" <pisoi (AT) hispeed (DOT) ch> writes: I've been looking for best practise regarding the use of throw() declarations and have been confronted with many different (and seemingly irreconcilable) points of view. In brief summary could be: 1) throw() declarations should be used extensively as it helps read/predict a program's behaviour 2) throw() declarations should not be used, or used as little as possible, to avoid portability issues and unexpected compiler behaviour 3) throw() declarations should be avoided with inline'd functions, but are ok otherwise I would appreciate further opinions/insight into these issues... All of those rules are too simplistic. The main advantage of 1) is that it can help to optimize a program's size, and sometimes its speed (http://groups.google.com/group/comp.lang.c++.moderated/msg/74e29c6c0054f9d3?hl=en&) Isn't the main advantage of 1) that it is a standard form of documentation, that is enforced by the compiler. Sort of enforced, anyway. Maybe, by a conforming compiler:-). At some point, when writing code, I need to know that certain functions don't throw. The only way I can know this (supposing I'm not personally the author of the code) is from the documentation. As documentation, throw() is a lot simpler to write than "This function is guaranteed not to throw". And for someone familar with the language, just as easy, if not easier to read. One point that hasn't been mentionned, however: a throw() declaration should not be used to document a function's current behavior. It defines a contract. If the contract of the function is that it will not throw, ever, then use throw(). If the function just happens not to throw, in its current implementation, but this is more or less accidental, and not part of the contract, do not use throw(). And when specifying the interface, don't accidentally guarantee more than you want to. In particular, don't guarantee no throw unless you really want to; you think it necessary, or useful, for this particular function. -- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Palik Imre Guest Posted: Sat Nov 05, 2005 11:32 am    Post subject: Re: wisdom of throw() declarations Paul Floyd <root (AT) 127 (DOT) 0.0.1> writes: Quote: On 3 Nov 2005 05:54:07 -0500, ICE <pisoi (AT) hispeed (DOT) ch> wrote: 1) throw() declarations should be used extensively as it helps read/predict a program's behaviour For legibility, comments can achieve this. 2) throw() declarations should not be used, or used as little as possible, to avoid portability issues and unexpected compiler behaviour 3) throw() declarations should be avoided with inline'd functions, but are ok otherwise See Hutter's Exceptional C++ Style for good coverage of this. Basically he says to never use them. Are there any drawbacks of using macros that are expanding to throw specifications in debug build, and nothing it release mode? ImRe [ 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 Nov 05, 2005 11:36 am    Post subject: Re: wisdom of throw() declarations "Gene Bushuyev" <blackhole (AT) spamguard (DOT) com> writes: Quote: Here is a summary of exception specifications (E.S.) pluses and minuses. Whether to use them and when, it's a decision depending on the particular circumstances. 1) E.S. create run-time checks. That means they won't help you at compile time. They document the intent, but at least at compile time that documentation is not better than a comment: both are not detected by compiler, and both can go out of synch. 2) E.S. may (and probably always do) impose run-time penalty and can prevent compiler optimizations. Not quite. They can impose a run-time penalty on certain, setjmp/longjmp-style EH implementations. On table-based implementations EH implementations they usually provide only performance advantages. Quote: 3) E.S. doesn't guarantee that the code can throw only listed exceptions. From the caller's perspective, yes, they do. Quote: Compiler just guarantees that it will shoot them on the spot, probably terminating your program as well. I know it sounds more dramatic that way, but you got that backwards. The compiler _guarantees_ termination(**) -- which at least is a lot more orderly than a crash. There's no actual shooting at all :) (**) unless you manage to install an unexpected_handler that translates into one of the listed exceptions, but the OP is asking about empty exception-specifications so translation is not an option. -- 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 Greg Herlihy Guest Posted: Sat Nov 05, 2005 6:36 pm    Post subject: Re: wisdom of throw() declarations kanze wrote: Quote: David Abrahams wrote: "ICE" <pisoi (AT) hispeed (DOT) ch> writes: I've been looking for best practise regarding the use of throw() declarations and have been confronted with many different (and seemingly irreconcilable) points of view. In brief summary could be: 1) throw() declarations should be used extensively as it helps read/predict a program's behaviour 2) throw() declarations should not be used, or used as little as possible, to avoid portability issues and unexpected compiler behaviour 3) throw() declarations should be avoided with inline'd functions, but are ok otherwise I would appreciate further opinions/insight into these issues... All of those rules are too simplistic. The main advantage of 1) is that it can help to optimize a program's size, and sometimes its speed (http://groups.google.com/group/comp.lang.c++.moderated/msg/74e29c6c0054f9d3?hl=en&) Isn't the main advantage of 1) that it is a standard form of documentation, that is enforced by the compiler. Sort of enforced, anyway. Maybe, by a conforming compiler:-). At some point, when writing code, I need to know that certain functions don't throw. The only way I can know this (supposing I'm not personally the author of the code) is from the documentation. As documentation, throw() is a lot simpler to write than "This function is guaranteed not to throw". And for someone familar with the language, just as easy, if not easier to read. One point that hasn't been mentionned, however: a throw() declaration should not be used to document a function's current behavior. It defines a contract. If the contract of the function is that it will not throw, ever, then use throw(). If the function just happens not to throw, in its current implementation, but this is more or less accidental, and not part of the contract, do not use throw(). And when specifying the interface, don't accidentally guarantee more than you want to. In particular, don't guarantee no throw unless you really want to; you think it necessary, or useful, for this particular function. If exception specifications were enforced by the compiler, then I would not expect this program: #include <stdexcept> int NoThrowFunction() throw() { throw std::runtime_error("not supposed to throw"); } int main() { NoThrowFunction(); } to compile. But I know of no C++ compiler that even so much as issues a warning when compiling this program, despite the fact that the "throw()" specification is widely believed to mean that the NoThrowFunction will not throw an exception. But in fact throwing an exception is all that the NoThrowFunction does in this program. So what does the throw() specification really guarantee? A throw() specification for a function really means that the caller will never be able to catch an exception emanating from the function - not because no such exceptions could be thrown - but because the app will halt the program should a thrown exception exit the function's scope. Sure the behavior is as if the function did not throw, but look at the price. Imagine a doctor claiming no patients ever died as the result of a certain treatment, but only because any who were about to die from it were euthanized first. The problem is that the exception specifications work in the opposite manner that most expect. They do not prevent routines from throwing exceptions, rather they prevent the program that calls such routines from executing. They perform no compile-time checks - so the detection of throw() specification violations that could be corrected by the programmer (such as the program above) is instead needlessly postponed until runtime where it could well be the customer who first runs into, and then somehow has to correct, the error. Greg [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top James Kanze Guest Posted: Sat Nov 05, 2005 6:40 pm    Post subject: Re: wisdom of throw() declarations Gene Bushuyev wrote: Quote: "ICE" <pisoi (AT) hispeed (DOT) ch> wrote in message news:dka6oi$oao$1 (AT) news (DOT) hispeed.ch... I've been looking for best practise regarding the use of throw() declarations and have been confronted with many different (and seemingly irreconcilable) points of view. In brief summary could be: 1) throw() declarations should be used extensively as it helps read/predict a program's behaviour 2) throw() declarations should not be used, or used as little as possible, to avoid portability issues and unexpected compiler behaviour 3) throw() declarations should be avoided with inline'd functions, but are ok otherwise I would appreciate further opinions/insight into these issues... Here is a summary of exception specifications (E.S.) pluses and minuses. Whether to use them and when, it's a decision depending on the particular circumstances. 1) E.S. create run-time checks. That means they won't help you at compile time. They document the intent, but at least at compile time that documentation is not better than a comment: both are not detected by compiler, and both can go out of synch. What is guaranteed is that a function with throw() will never throw. If by error it does, you get an immediate program termination, rather than some unexpected and perhaps difficult to track down behavior because the calling code counted on it not throwing. It's far from being as good as a compile time error, but it's probably better than nothing. Quote: 2) E.S. may (and probably always do) impose run-time penalty and can prevent compiler optimizations. I would expect the reverse. If the compiler knows that a function cannot throw, it has less flow paths to deal with in the calling code, which simplifies optimization. As David has pointed out, throw() may (probably does) mean an implicit try/catch block in the calling code. However, such blocks have 0 runtime overhead with at least one of the compilers I use (Sun CC); there is a space overhead in terms of virtual memory, but it is possible to put this in a separate segment, so it will only be loaded if an exception actually occurs. Quote: 3) E.S. doesn't guarantee that the code can throw only listed exceptions. Compiler just guarantees that it will shoot them on the spot, probably terminating your program as well. Violation of E.S. causes unexpected() function to be called. You can install your own handler, but you are unlikely to do anything useful with that other than terminating your application. The question specifically concerned throw(). There seems to be a general consensus that throw( something ) is useless, at best, and probably harmful. Quote: 4) E.S. cannot be typedef-ed, but function pointers can easily be assigned. That's a flaw in the language, I think. Quote: 5) E.S. participate in function overriding. It's good of course that the base class contract is enforced. But when designing base class, it's rarely possible to know all the exceptions the derived classes should be able to throw. It's easier to foresee what you don't want your derived functions to throw. But there is no such thing as negative E.S. except for throw(). It's a question of contract. As I mentionned in my response to David, you don't want to use throw() just because the function doesn't happen to throw in its current implementation. You use it when you want a contractual guarantee that the function doesn't throw. If the base class says that virtual function f() gives this guarantee, then all derived classes had better conform. (On the other hand, I think we'd agree that the base class shouldn't make this part of the contract without a good reason.) -- James Kanze mailto: [email]james.kanze (AT) free (DOT) fr[/email] Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34 [ 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: Sun Nov 06, 2005 12:12 pm    Post subject: Re: wisdom of throw() declarations Palik Imre <clcppm-poster (AT) this (DOT) is.invalid> writes: Quote: Paul Floyd <root (AT) 127 (DOT) 0.0.1> writes: On 3 Nov 2005 05:54:07 -0500, ICE <pisoi (AT) hispeed (DOT) ch> wrote: 1) throw() declarations should be used extensively as it helps read/predict a program's behaviour For legibility, comments can achieve this. 2) throw() declarations should not be used, or used as little as possible, to avoid portability issues and unexpected compiler behaviour 3) throw() declarations should be avoided with inline'd functions, but are ok otherwise See Hutter's Exceptional C++ Style for good coverage of this. Basically he says to never use them. Are there any drawbacks of using macros that are expanding to throw specifications in debug build, and nothing it release mode? You may miss some release mode optinizations for empty exception specifications. I don't see any advantage to having exception specifications on in a debug build, though. -- 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 Gene Bushuyev Guest Posted: Sun Nov 06, 2005 12:15 pm    Post subject: Re: wisdom of throw() declarations "James Kanze" <kanze (AT) none (DOT) news.free.fr> wrote Quote: Gene Bushuyev wrote: "ICE" <pisoi (AT) hispeed (DOT) ch> wrote in message news:dka6oi$oao$1 (AT) news (DOT) hispeed.ch... [...] 1) E.S. create run-time checks. That means they won't help you at compile time. They document the intent, but at least at compile time that documentation is not better than a comment: both are not detected by compiler, and both can go out of synch. What is guaranteed is that a function with throw() will never throw. If by error it does, you get an immediate program I guess it all depends on the definition of "guarantee" (or the definition of "is"). The only thing the standard guarantees is that you won't catch any exceptions from throw() function in a usual way, instead you can "catch" them in unexpected handler. In my book it's not the same as guaranteeing that there is no exception thrown. I think a conventional meaning of no-throw/no-fail guarantee is that the program works (not crashes) and no exceptions are thrown. Look at this this way. What do you need to do to make a destructor or a swap function to never fail? Simply adding throw() specification? If that were a "guarantee" then I must answer - yes. Quote: termination, rather than some unexpected and perhaps difficult to track down behavior because the calling code counted on it not throwing. It's far from being as good as a compile time error, but it's probably better than nothing. 2) E.S. may (and probably always do) impose run-time penalty and can prevent compiler optimizations. I would expect the reverse. If the compiler knows that a function cannot throw, it has less flow paths to deal with in the calling code, which simplifies optimization. You are right, the caller may have less to do with the function that has throw() specification. But the function itself has more to do to catch all the possible exceptions and direct them to unexpected handler. Since on the caller side there will probably other functions that can throw, this opportunity for optimization may never materialize. But the penalty for the throw() function itself is always there. Quote: As David has pointed out, throw() may (probably does) mean an implicit try/catch block in the calling code. However, such blocks have 0 runtime overhead with at least one of the compilers I use (Sun CC); there is a space overhead in terms of virtual memory, but it is possible to put this in a separate segment, so it will only be loaded if an exception actually occurs. Well, I guess it's an open question. Existing compilers probably show pretty different results and I haven't seen so far any profiling and objective research of this topic, so we are all mostly engaged in speculations here. I wish somebody who has more free time on their hands tried to profile different scenarios on different compilers. -- Gene Bushuyev ---------------------------------------------------------------- There is no greatness where there is no simplicity, goodness and truth. ~ Leo Tolstoy [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Gene Bushuyev Guest Posted: Sun Nov 06, 2005 12:16 pm    Post subject: Re: wisdom of throw() declarations "David Abrahams" <dave (AT) boost-consulting (DOT) com> wrote Quote: "Gene Bushuyev" <blackhole (AT) spamguard (DOT) com> writes: [...] 3) E.S. doesn't guarantee that the code can throw only listed exceptions. From the caller's perspective, yes, they do. Compiler just guarantees that it will shoot them on the spot, probably terminating your program as well. I know it sounds more dramatic that way, but you got that backwards. The compiler _guarantees_ termination(**) -- which at least is a lot more orderly than a crash. There's no actual shooting at all After all, I'm interested in no-fail guarantee, not that I won't catch an exception guarantee. The former gives me a lot of power the latter doesn't help me at all. How would guaranteeing termination help me in the program design? After all, it's easier to deal with exceptions then with unexpected handler. It looks like a backward move to pre-exception times. -- Gene Bushuyev ---------------------------------------------------------------- There is no greatness where there is no simplicity, goodness and truth. ~ Leo Tolstoy [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Niklas Matthies Guest Posted: Mon Nov 07, 2005 9:31 am    Post subject: Re: wisdom of throw() declarations On 2005-11-06 12:12, David Abrahams wrote: Quote: Palik Imre <clcppm-poster (AT) this (DOT) is.invalid> writes: : Are there any drawbacks of using macros that are expanding to throw specifications in debug build, and nothing it release mode? You may miss some release mode optinizations for empty exception specifications. I don't see any advantage to having exception specifications on in a debug build, though. It makes sure you notice when an exception is thrown where none was expected. -- Niklas Matthies [ 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.