views:

174

answers:

1

Recently a colleague asked my opinion on the use of exception specifications in C++ code, and I was able to dredge up this article by Herb Sutter: A Pragmatic Look at Exception Specifications. The article, like most by Herb Sutter, is an educational read, but the short answer is "don't do that."

In the summary, he makes reference to a poem entitled "Twas the Night Before Implementation", wherein, effectively, a standards committee bows to the demands of users to add a feature at the last minute, only to discover that while it does what was asked for, it doesn't really do what they wanted. And yes, exception specifications fit that bill. As he says, "The feature seemed like a good idea at the time, and it is just what some asked for." If that is not enough, he then visits ''export'' with similar sad results.

So the question is this: What 'feature' of C++ turns out to be broken, and should not be used, if you do not wish to experience tears. This may be prey to subjective bickering, but I hope people will cite a specific experience where the feature was deployed only to cause measurable problems. Even better would be citations of articles by leading lights like Sutter (or anyone deeply involved in the Standard) warning people off of a feature.

+5  A: 

If you include library features as well: auto_ptr. It has its uses but it's also easy to misuse. The next C++ standard will deprecate them as well in favor of the safer and more flexible std::unique_ptr.

sellibitze