Exception Specification Compromise
in [C++]
|
From: Torsten Robitzki on 9 Feb 2010 08:16 DeMarcus schrieb: > The only thing I'm asking for is an optional feature in the compiler > that warns me if a function, declared throw(), contains any function not > declaring throw(). That's it! The rest I can do myself. Maybe, you can find such feature with some static code analyser like pc-lint or QAC++. best regards Torsten -- kostenlose Wirtschaftssimulation: http://www.financial-rumors.de [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: DeMarcus on 9 Feb 2010 08:17 > > And part ofg that mechanism will have to be a way to reassure the > compiler that a function call will not throw (or to put it another way, > if it does then the programmer takes full responsibility) > > Just for the purposes of exposition: > > int foo(int); // programmer has not declared foo > // not to throw > > int bar() nothrow { > int i(nothrow foo(0)); // assures compiler that > // this call will not thorw > // more code > } > > I think that some such mechanism is necessary to deal with the many > existing libraries where perfectly reasonable functions that will not > throw have not been declared as not throwing. > > Yes, you're right, but to make it simple, i.e. keep the fingers away from the standard, we can solve it like this for now. int foo(int); // programmer has not declared foo // not to throw int bar() throw() { try { int i(foo(0)); } catch(...) {} // assures compiler that // this call will not thorw // more code } -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Francis Glassborow on 9 Feb 2010 08:18 DeMarcus wrote: >>> I fully agree that some mechanism to statically enforce/analyse the >>> no-throw guarantee would be very welcome! >> >> The problem is one of technology. With the linking model we use now, >> it is impossible. And changing the model does not really change >> anything. >> Determining if a function can throw is to the best of my knowledge not >> possible, and if it is, surely it will be computationally to expensive >> to be usable. >> Just take a simple function like: >> >> std::vector<int> f() >> { >> std::vector<int> res(200000); >> return res; >> } >> >> You can't determine if that function might throw unless you know what >> new_handler is installed. >> >> /Peter >> > > Just to not diverge from the original thread I want to emphasize that > the idea is to track no-throw functions only. Please note that the idea > is also intended as an optional feature in the compiler. In other words, > those who do not want to use it and/or have a reason to throw from > no-throw functions like destructors, pop or cleanup functions in > general, will not be affected if they choose not to use the particular > compiler flag. > > The problems during linking, as you describe, will actually not be a > problem. The main idea is simple; we just want to make sure no-throw > functions are actually no-throw. Therefore the optional compiler feature > would work like this. > > * If a function is declared throw() it is a no-throw function. If it is > not declared throw() it may throw whatever, according to the compiler. > > * If a throw()-declared function contains any function that is not > declared throw(), we get a warning. And there is the problem. You need a way to assure the compiler that a function call will not result in an exception even though the function does not have a throw spec. Just as an example, how many library (both standard and third party) have throw specs on their dtors? You cannot just add a throw spec yourself because that changes the interface and may result in unwanted added code. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: DeMarcus on 9 Feb 2010 08:17 >> Maybe I should clarify that the standard does *not* need to be touched. >> Not even the libraries have to be touched! >> >> The only thing I'm asking for is an optional feature in the compiler >> that warns me if a function, declared throw(), contains any function not >> declaring throw(). That's it! The rest I can do myself. > > > Then just about every function will issue a warning because there are > far too many library functions that cannot throw bot have no exception > spec on their declaration. You would get so many warnings with no good > way to fix them that you would soon get tired of it. > You have a point! However, as for my own code I would start fix it in this end; 1. Turn on the compiler flag. 2. In my own project (not libraries), start declare throw() for the no-throw functions. 3. For each function changed to throw(), check if we get a compiler warning. If so, in the function's contents, embrace non-project functions with try/catch(...). E.g. try { myVector.pop_back(); } catch(...) {} 4. Iterate over all no-throw functions in the project until all are declared throw(). The try/catch(...) will tell the compiler that this library function can be seen as declared throw(), hence the warning will disappear. Now, to get back to your comment, correct me if I'm wrong, but the only places where we would get warnings we cannot fix is in template libraries (like the STL), where a function declared throw() uses functions not declared throw(). As I understand it, throw() is sparsely used in template libraries, hence we would probably not get that many warnings. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Seungbeom Kim on 9 Feb 2010 08:18
DeMarcus wrote: >>> I fully agree that some mechanism to statically enforce/analyse the >>> no-throw guarantee would be very welcome! >> >> The problem is one of technology. With the linking model we use now, >> it is impossible. And changing the model does not really change >> anything. >> Determining if a function can throw is to the best of my knowledge not >> possible, and if it is, surely it will be computationally to expensive >> to be usable. >> Just take a simple function like: >> >> std::vector<int> f() >> { >> std::vector<int> res(200000); >> return res; >> } >> >> You can't determine if that function might throw unless you know what >> new_handler is installed. >> >> /Peter >> > > Just to not diverge from the original thread I want to emphasize that > the idea is to track no-throw functions only. [...] [...] > > * If a function is declared throw() it is a no-throw function. If it is > not declared throw() it may throw whatever, according to the compiler. > > * If a throw()-declared function contains any function that is not > declared throw(), we get a warning. I'm afraid you don't seem to understand. Take the following function for example: std::vector<int> f() throw() { std::vector<int> res(200000); return res; } Peter's argument was that it was impossible for the compiler to determine whether a function (like the one above) might throw. How should your optional compiler feature respond to this? -- Seungbeom Kim [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |