C++Talk.NET C++ language newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Why are there exception specifications in the standard libra Goto page 1, 2, 3  Next          C++Talk.NET Forum Index -> C++ Language (Moderated) View previous topic :: View next topic   Author Message BigMan Guest Posted: Mon Apr 18, 2005 9:06 am    Post subject: Why are there exception specifications in the standard libra The C++ standard defines some classes that have methods declared as throw( ) (e.g. std::auto_ptr, std::locale). In the same time, C++ experts teach us why exception specs (even throw()) are bad and that we should avoid them. So, why has the committee decided to supply some standard functions with exception specifications? What is the rationale behind their decision? [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top I.J.Wang Guest Posted: Tue Apr 19, 2005 10:15 pm    Post subject: Re: Why are there exception specifications in the standard "BigMan" <BigMan (AT) abv (DOT) bg> wrote Quote: The C++ standard defines some classes that have methods declared as throw( ) (e.g. std::auto_ptr, std::locale). In the same time, C++ experts teach us why exception specs (even throw()) are bad and that we should avoid them. So, why has the committee decided to supply some standard functions with exception specifications? I feel C++ standard committee has its problem to solve. Being a user, I am smart enough (probably not enough) avoid digging these issues. Experts teach their experience at that time (may trim their words latter as the standard may interpret as well), users are on their own. throw() is necessary for some fundamental library functions, but the real implement code may be empty. Quote: What is the rationale behind their decision? It is that exception specification exists first, then the experts feel it is bad and teach people to avoid, then the 3rd user confuses. Exception specification is, for I know, to provide compile time check and optimization. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Torsten Robitzki Guest Posted: Tue Apr 19, 2005 10:15 pm    Post subject: Re: Why are there exception specifications in the standard BigMan wrote: Quote: The C++ standard defines some classes that have methods declared as throw( ) (e.g. std::auto_ptr, std::locale). In the same time, C++ experts teach us why exception specs (even throw()) are bad and that we should avoid them. So, why has the committee decided to supply some standard functions with exception specifications? What is the rationale behind their decision? To implement exception (or error) save code you need some functions to recover from errors where you must be sure that they can not run into an error condition again. regards Torsten [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Allan W Guest Posted: Tue Apr 19, 2005 10:59 pm    Post subject: Re: Why are there exception specifications in the standard l BigMan wrote: Quote: The C++ standard defines some classes that have methods declared as throw( ) (e.g. std::auto_ptr, std::locale). In the same time, C++ ^^^^^^^^^^^^^^^^ experts teach us why exception specs (even throw()) are bad and that we should avoid them. So, why has the committee decided to supply some standard functions with exception specifications? What is the rationale behind their decision? What the experts have said about exception specs, was said long after the C++ standard was completed (1998). Much has been learned since then. To anyone that knows: in C++200x, are changes being contemplated to exception specs? What's being considered? [ 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: Wed Apr 20, 2005 12:36 pm    Post subject: Re: Why are there exception specifications in the standard BigMan wrote: Quote: The C++ standard defines some classes that have methods declared as throw( ) (e.g. std::auto_ptr, std::locale). In the same time, C++ experts teach us why exception specs (even throw()) are bad and that we should avoid them. That's news to me. I know that a number of experts don't like general exception specifications, but I don't think that there is a consensus that throw() (to say that a function doesn't throw) is bad. Quote: So, why has the committee decided to supply some standard functions with exception specifications? What is the rationale behind their decision? Several reasons. One, the standard was written before the experts came to their conclusion. Also, the standard is defining interfaces, not actual implementations. Regardless of the merits of exception specifications in compilable code, they are a readable convention for specifying to a user which exceptions a function might throw. -- 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 Jean-Sebastien Samson Guest Posted: Wed Apr 20, 2005 8:49 pm    Post subject: Re: Why are there exception specifications in the standard Quote: That's news to me. I know that a number of experts don't like general exception specifications, but I don't think that there is a consensus that throw() (to say that a function doesn't throw) is bad. Actually throw() does not say a function doesn't throw. It more or less asks the compiler to add implicit catch statements to ensure the function does not throw (and if the function does, those statements terminate the program). This is not exactly what one would expect and that's why it is not such a good thing. -- JS [ 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: Thu Apr 21, 2005 12:05 pm    Post subject: Re: Why are there exception specifications in the standard l Jean-Sebastien Samson wrote: Quote: That's news to me. I know that a number of experts don't like general exception specifications, but I don't think that there is a consensus that throw() (to say that a function doesn't throw) is bad. Actually throw() does not say a function doesn't throw. It more or less asks the compiler to add implicit catch statements to ensure the function does not throw (and if the function does, those statements terminate the program). This is not exactly what one would expect and that's why it is not such a good thing. It depends from which side you are looking at things. As a client, the presence of throw() very definitly does guarantee that I will not get an exception from the function. That sounds exactly what I would expect. For that matter, when implementing the function, it means that I am not allowed to leave the function by an exception (unless I really do want to terminate the program brutally). That's really what I would expect, too -- throw() means that I'm not allowed to leave the function via an exception. The fact that it results in an abort is in some ways a bit strange. Most of the time, when I do something that isn't allowed (e.g. dereference a nul pointer), I get undefined behavior (although typically, on my implementations, the program also terminates abnormally). But I'm not one to argue in favor of adding undefined behavior. I'm just curious: what do you expect it to mean which is different? -- 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 Mary K. Kuhner Guest Posted: Thu Apr 28, 2005 12:41 pm    Post subject: Re: Why are there exception specifications in the standard l In article <1114074309.750358.51730 (AT) z14g2000cwz (DOT) googlegroups.com>, <kanze (AT) gabi-soft (DOT) fr> wrote: [Throwing from a function which is marked "throw()"] Quote: The fact that it results in an abort is in some ways a bit strange. Most of the time, when I do something that isn't allowed (e.g. dereference a nul pointer), I get undefined behavior (although typically, on my implementations, the program also terminates abnormally). But I'm not one to argue in favor of adding undefined behavior. I'm just curious: what do you expect it to mean which is different? While I realize that this is insanely difficult, it would be be *so* nice if it meant "This function won't compile if it is capable of throwing an exception." I think that's a common intuition for what it means, just as if you violate const- correctness you don't get abnormal termination or undefined behavior, you get a program that flatly doesn't compile. I guess there are two awful problems with this, the first being that it's very hard for the compiler to prove a function can't call an exception, and the second being that sometimes the programmer can prove it in a case where the compiler can't, and we would like to be able to mark such functions "throw()". Mary Kuhner [email]mkkuhner (AT) gs (DOT) washington.edu[/email] [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Nicola Musatti Guest Posted: Fri Apr 29, 2005 8:33 am    Post subject: Re: Why are there exception specifications in the standard l Mary K. Kuhner wrote: [...] Quote: While I realize that this is insanely difficult, it would be be *so* nice if it meant "This function won't compile if it is capable of throwing an exception." I think that's a common intuition for what it means, just as if you violate const- correctness you don't get abnormal termination or undefined behavior, you get a program that flatly doesn't compile. I don't think it would be very good. You'd soon find yourself in a position in which every one of your functions has to take into account all the exceptions that might be thrown by the functions it calls. For a device designed to allow error notification across nested calls I'd consider this a major drawback. Quote: I guess there are two awful problems with this, the first being that it's very hard for the compiler to prove a function can't call an exception, and the second being that sometimes the programmer can prove it in a case where the compiler can't, and we would like to be able to mark such functions "throw()". This is actually not very difficult: you make it an error for a function with a throw() exception specification to either contain throw statements or calls to functions that do not have the same specifications. Cheers, Nicola Musatti [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top ThosRTanner Guest Posted: Fri Apr 29, 2005 4:36 pm    Post subject: Re: Why are there exception specifications in the standard l Nicola Musatti wrote: Quote: Mary K. Kuhner wrote: [...] While I realize that this is insanely difficult, it would be be *so* nice if it meant "This function won't compile if it is capable of throwing an exception." I think that's a common intuition for what it means, just as if you violate const- correctness you don't get abnormal termination or undefined behavior, you get a program that flatly doesn't compile. I don't think it would be very good. You'd soon find yourself in a position in which every one of your functions has to take into account all the exceptions that might be thrown by the functions it calls. For a device designed to allow error notification across nested calls I'd consider this a major drawback. Why wouldn't this be very good? Isn't it the situation that if your function has an exception specification, and a function it calls happens to throw an exception which isn't in your specification, then you'll get a (more or less) fatal runtime error anyway. How is it a drawback for this to be detected at compile time rather than run time? For those of use who write systems where crashing is not acceptable, we can't use exception specifications, because of this (IMHO insane) behaviour, even though we would like to. To allow error notification across nested calls, you have to use no exception specification, or specify all possible exceptions (or a common base class which would be quite sensible), or risk your program dying horribly. Quote: I guess there are two awful problems with this, the first being that it's very hard for the compiler to prove a function can't call an exception, and the second being that sometimes the programmer can prove it in a case where the compiler can't, and we would like to be able to mark such functions "throw()". This is actually not very difficult: you make it an error for a function with a throw() exception specification to either contain throw statements or calls to functions that do not have the same specifications. That would be so nice... (but I think you'd have to make extern "C" functions implicitly throw(), and of course, destructors should be implicitly throw() anyway). [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Jerry Coffin Guest Posted: Sat Apr 30, 2005 11:23 am    Post subject: Re: Why are there exception specifications in the standard l Mary K. Kuhner wrote: [ ... exception specification of 'throw()' ] Quote: While I realize that this is insanely difficult, it would be be *so* nice if it meant "This function won't compile if it is capable of throwing an exception." I think that's a common intuition for what it means, just as if you violate const- correctness you don't get abnormal termination or undefined behavior, you get a program that flatly doesn't compile. This would correspond pretty closely with what Java calls a checked exception. While it initially looks like a good idea to many people, it doesn't seem to work out that way in practice (at least as a rule). If you Google for "Java checked exception", you'll find quite a few papers about the problems they cause. Quote: I guess there are two awful problems with this, the first being that it's very hard for the compiler to prove a function can't call an exception, and the second being that sometimes the programmer can prove it in a case where the compiler can't, and we would like to be able to mark such functions "throw()". Actually, it's not all that difficult for the compiler to do: it basically proves that this function doesn't use throw directly (pretty trivial) and that if it calls a function either 1) that function doesn't throw either (in the same way), or 2) anything it throws will be caught and not re-thrown. That would clearly add some complexity to the compiler, but I'm pretty sure if it was required in C++, it wouldn't be anywhere close to the most difficult/complex part of the compiler. OTOH, given the problems they seem to cause, I'm glad it's not a required in C++. -- Later, Jerry. The universe is a figment of its own imagination. [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top wade@stoner.com Guest Posted: Sat Apr 30, 2005 4:00 pm    Post subject: Re: Why are there exception specifications in the standard l ThosRTanner wrote: Quote: How is it a drawback for this to be detected at compile time rather than run time? For those of use who write systems where crashing is not acceptable, we can't use exception specifications ... I assume that you also don't use signed integer arithmetic, because the compiler usually can't tell if it will invoke UB, and you also don't use local variables, because the compiler can't tell if they will cause stack overflow, ... In some circumstances it might be nice to have a compiler that tells me when it notices that int i = rand(); ++i; might overflow or exceed the available stack space, but somehow I suspect that I'd turn off those warnings, unless they were restricted to cases where the compiler was pretty sure there was a problem. If you're going to use C++, you're probably going to do a lot of things that the compiler can't prove are safe. If you want to prove your code is safe, you'd better use another set of tools. [ 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 Apr 30, 2005 4:13 pm    Post subject: Re: Why are there exception specifications in the standard l "Jerry Coffin" <jcoffin (AT) taeus (DOT) com> writes: Quote: Mary K. Kuhner wrote: [ ... exception specification of 'throw()' ] While I realize that this is insanely difficult, it would be be *so* nice if it meant "This function won't compile if it is capable of throwing an exception." I think that's a common intuition for what it means, just as if you violate const- correctness you don't get abnormal termination or undefined behavior, you get a program that flatly doesn't compile. This would correspond pretty closely with what Java calls a checked exception. While it initially looks like a good idea to many people, it doesn't seem to work out that way in practice (at least as a rule). If you Google for "Java checked exception", you'll find quite a few papers about the problems they cause. What Mary is talking about, though, is a simple "can throw/can't throw" distinction. Most of us (even hard core exception-specification critics like me) think this wouldn't cause nearly the same kinds of problems, and might even be a huge win if destructors were automatically marked "can't throw" unless otherwise specified. It certainly would allow some optimizations that currently are only possible if you use throw() everywhere it's possible. -- 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 M Jared Finder Guest Posted: Sun May 01, 2005 10:53 am    Post subject: Re: Why are there exception specifications in the standard l Mary K. Kuhner wrote: Quote: In article <1114074309.750358.51730 (AT) z14g2000cwz (DOT) googlegroups.com>, [email]kanze (AT) gabi-soft (DOT) fr[/email]> wrote: [Throwing from a function which is marked "throw()"] The fact that it results in an abort is in some ways a bit strange. Most of the time, when I do something that isn't allowed (e.g. dereference a nul pointer), I get undefined behavior (although typically, on my implementations, the program also terminates abnormally). But I'm not one to argue in favor of adding undefined behavior. I'm just curious: what do you expect it to mean which is different? While I realize that this is insanely difficult, it would be be *so* nice if it meant "This function won't compile if it is capable of throwing an exception." I think that's a common intuition for what it means, just as if you violate const- correctness you don't get abnormal termination or undefined behavior, you get a program that flatly doesn't compile. I guess there are two awful problems with this, the first being that it's very hard for the compiler to prove a function can't call an exception, and the second being that sometimes the programmer can prove it in a case where the compiler can't, and we would like to be able to mark such functions "throw()". I like this idea (*optionally* specified throw specifications) a lot, but I don't think C++ has the proper tools to make this usable. While a flow analysis program can use brute force to prove if a C++ function would ever throw, analyzing all 8^32 (now 8^64 with 64 bit cpus) states is impractical. For the throw specifications to be able to be practically checked at compile time, you'd need to be able to tell the compiler when a function doesn't throw with finer granularity than function calls. I'm envisioning a more granular type system, where you could say: sqrt is a function that maps positive integers to positive integers, zero to zero, and negative numbers to exceptional situations. Then, if it could be proven that sqrt is only called with non-negative numbers in a particular function (possibly because it asserts that it will only be passed numbers in the range 0 to 100), then that function will not throw because of sqrt. The major disadvantage I see of a system like this is the sheer amount of extra crap I have to type. Much like what's happening with const correctness, I highly doubt that most projects would put enough work into using such a system to see any benefit. Not enough common errors are caught with this system for it to be psychologically pleasing. -- MJF [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] Back to top Peter C. Chapin Guest Posted: Sun May 01, 2005 10:59 am    Post subject: Re: Why are there exception specifications in the standard l "Jerry Coffin" <jcoffin (AT) taeus (DOT) com> wrote in news:1114784941.342257.247600 (AT) o13g2000cwo (DOT) googlegroups.com: Quote: Actually, it's not all that difficult for the compiler to do: it basically proves that this function doesn't use throw directly (pretty trivial) and that if it calls a function either 1) that function doesn't throw either (in the same way), or 2) anything it throws will be caught and not re-thrown. What about the case when a function calls a function that can throw, but does so in such a way that it won't? For example: void f() { if (some_complex_error_checking() == ALL_OK) { g(); } } So g() might be declared to throw an exception but under these particular circumstances the programmer might know that it won't in this case. Thus the programmer can declare f() as not throwing any exceptions. It would be hard for the compiler to figure this out. It's my understanding that this is the main argument against static checking of exception specifications. That is, if g() is declared to throw an exception but f() is declared to throw none, the compiler would complain about code that is actually perfectly acceptable. To keep the compiler happy the programmer would have to add unnecessary try/catches or declare f() to throw an exception he/she knows it won't. Peter [ 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.