Exception Specification Compromise
in [C++]
|
From: Öö Tiib on 10 Feb 2010 08:16 On Feb 10, 8:36 am, DeMarcus <use_my_alias_h...(a)hotmail.com> wrote: > > > I don't know how to deal with that. > You see there are issues and some are hard to workaround, diagnose or overcome. Function/member function pointers and so on. It may happen that such option is quite close to bottom of wish lists of standard makers, library makers and compiler makers. Maybe leave them all alone and write a static code analyzing tool yourself. Tool needs not to compile nor link the code. Only check it and provide diagnostics about the very issue. Also you can check the reverse issue like "this function can never throw but lacks throw() specification." Once there will be huge demand for your tool on the market, then perhaps compiler makers will add such diagnostic to their compilers as well. ;) -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: DeMarcus on 10 Feb 2010 08:17 > > Sorry but this is simply not the way to go. I know that WG21 has been > considering a nothrow attribute to assist compilers. > Ah, I see. That may be what's needed. I didn't know there were things going on. For others, you can read more here. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2855.html -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: peter koch larsen on 10 Feb 2010 08:15 On 10 Feb., 07:35, DeMarcus <use_my_alias_h...(a)hotmail.com> wrote: > Seungbeom Kim wrote: > > 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. [snip] > > >> 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? > > Maybe I miss something, but wouldn't the compiler be able to see that > std::vector's constructor is declared without throw()? Exactly. This is because it can throw (when instantiated with an int) an out of memory exception. But if we install a new_handler that terminates the process when called, the above function will never throw and would thus be a safe function. > > The std::vector's constructor is not declared throw(), hence the > compiler can easily see that f() might throw, or actually crash since > f() is declared throw() which will stop all exceptions. In your example > the compiler would give a warning that f() is declared no-throw but > calls functions not declared no-throw. And such warnings would abound - for how many functions can you really call that will never throw. The example above was slightly contrived, but there are lots of cases where the function will not be declared throw() but the call wont throw. This could be because the parameters are checked, because the original author did not use an empty exception specification or because the author could not use an empty exception specification e.g because the function is a template. > > However, something that I don't know is the following. > > std::vector<int> f() throw() > { > try > { > std::vector<int> res(200000); > return res; > } > catch(...) {} > > } > > Will the copy to the return value be embraced by the try/catch(...)? > I don't know. Does anyone know? The code above will not return anything: you need to put something in the catch clause. > > One thing I know though, is that no-throw operations should not return > values that must use a copy constructor (see Exceptional C++ by Herb > Sutter, Item 10). That is why pop_back() never returns the popped value. That depends entirely on the copy-constructor. > > I mean, already here we see the effect of the static check. If someone, > from a no-throw function, returns a value that uses the copy constructor > we will get a warning. No. /Peter -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: Nevin :-] Liber on 10 Feb 2010 08:16 In article <82be602f-bb4e-45af-a04e-fcbeee7fdd02(a)z17g2000yqh.googlegroups.com>, ThosRTanner <ttanner2(a)bloomberg.net> wrote: > That function *might* throw because the constructor for > std::vector<int> isn't declared throw(). > > A function won't throw if and only if the only functions it calls > doesn't throw (and it doesn't throw itself of course). What you can > never tell is if it it will throw but I don't think that's important. > > It is trivially easy to statically analyse whether or not a function > might throw. You can even tell precisely what it might throw. Not without whole program analysis. For instance, how can you tell if the function qsort throws? You have to analyze the compare function, which might be determined at run time. Worse, what happens if that compare function calls a global function stored in a tr1::function? If the poster is really asking for a compiler extension, I'm not sure why he is posting it here instead of asking his compiler vendor (along with how much he is willing to contribute or pay to make it happen). Personally, I don't see much traction on this, as most folks just aren't seeing these kinds of issues very frequently (if at all) when using exceptions in day to day usage. -- Nevin ":-)" Liber <mailto:nevin(a)eviloverlord.com> 773 961-1620 [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ]
From: DeMarcus on 10 Feb 2010 08:17
Francis Glassborow wrote: > DeMarcus wrote: >>> >>> 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 >> } > > But that is exactly the kind of added complexity that I do not want to > clutter my code with. > That is why I proposed it as an optional feature so that it won't affect nobody except those who see it as a help. As for me, until this no-throw issue has gotten a clean solution, I prefer this clutter code to a core dump. However, I realize that the discussion about exception specifications in C++ is soo infected that nobody dares to touch it but instead stick to a set mind how things should work. I bought the book Exceptional C++ by Herb Sutter. It's an excellent book, buy it. However, even Sutter himself seems to be totally paralyzed when it comes to exception specifications, as I found when I surprisingly read the following. "Writing throw() limits you in the future in case you want to change the underlying implementation to a form that could throw.", page 54. Now, anyone in this community, raise a hand if you would be happy if one of your programmers or colleagues suddenly started to throw from a no-throw function. It's a silent and efficient way to put a company in Chapter 11. -- [ See http://www.gotw.ca/resources/clcm.htm for info about ] [ comp.lang.c++.moderated. First time posters: Do this! ] |