Jonathan Wakely said: > Simon Hill wrote: > > Brain Dessent wrote: > >> You're essentially trusting that all > >> exception specifiers for every function in the program and *all* library > >> code are always present and always correct which is a huge leap of faith > >> that I don't think is supported by reality. > > > > I agree that it won't be very useful initially due to lots of third > > party code like boost neither defining nor adhering exception > > restrictions 100% of the time (STL may be guilty also). However, this > > is a catch 22. Why not provide the mechanism for verifying exception > > specifications so that these libraries can, in future, become fully > > compliant? > > That won't happen. Boost and the standard library are not "guilty" of > anything. The standard library components *are* fully compliant to the > ISO standard by definition, and the omission of exception > specifications is (in almost all cases) completely intentional. > > Some people might find the warning useful, but please don't assume > that code without exception specifications is incomplete, or would > necessarily benefit from having them.
Sorry about that, bad choice of words - I didn't intend to imply they were flawed because they didn't comply, and complying was only intended to mean voluntarily adhering to the idea of strict exception specifiers, not complying with the C++ standard. You're probably right that it won't happen in the near future. However if modifications like this actually become popular and easy enough to use they may make exception restrictions in STL, boost etc. desirable enough for people to alter the specs of those libraries - or at least create alternate versions. Brendon Costa wrote: > What is the benefit of exception specifiers that can not be provided > with documentation It's similar to the benefits I'm most looking forward to in c++0x concepts - a way for the compiler to tell me off clearly when I do something bad like accidentally allow a type of exception to propagate far farther than I intended. (The concept analogue does things like prevent you from declaring a std::vector of a type that has no copy or move constructor (it spits an error)). I much prefer the compiler enforcing things like this than have them simply be stated in documentation that may not even be read. (Concepts are of course slightly different in that without them you're still unable to compile code that is missing the necessary functions, but they're close enough for this comparison.) Also, documentation has to be held in the head (unless you refer to hardcopy every time you write a function) and mine has a lot of holes. My view is that this would lead me to making more robust code that handles the unavoidable exceptions (disk errors etc) cleanly in _every_ case, while I spend less time thinking about this. Of course I'm trading for the time it takes to code everything with appropriate exception specifiers (but this isn't difficult, merely a bit tedious). Brendon Costa wrote: > What i mentioned in an earlier post is that rather than a function > specify what it can throw, i propose that for the C++ community a more > useful compile time assertion is to allow code that uses a function to > define what exceptions it can deal with that function throwing. I.e. > moving the contract from the used to the user. I'm not 100% sure how you proposed to fix this, but couldn't you look at rigid exception specifications as achieving this? Because there's two parts to it: 1) calling function defines the maximum set of exceptions that callee can throw (isn't this the same thing as you're asking?) in it's own declaration throw() clause and inner catch() clauses. And if you really wanted a specific set of exceptions for just one call you could create a wrapper function with this set as it's throw() clause. 2) callee defines the minimum set of exceptions that caller must handle. (Sorry I don't have time now to look up that post, I gotta leave). ASIDE: I just realized that the most interesting coming features for me are things that stop you doing stuff. Concepts and Contracts. That's probably related to why I'd like this project. Anyway, it's the weekend, time to begin soon (and soon time to remember about all those wonderful things that C can't do :)
