Exception Specifications in the Library --------------------------------------- 26-Jan-95 by Nathan Myers X3J16/95-0020 Rogue Wave Software WG21/N0620 The Library WG has resolved to add exception specifications to all library functions. Writing a proposal to add such specifications to the whole library is a very big job. One beginning such an effort deserves to expect that the outcome will be largely acceptable to the committee, and to know which choices should be left up to the committee. This proposal outlines such a policy. We begin by noting that "no exception specification" is (implicitly) an exception specification; it indicates the function may throw any exception at all. Therefore, in a sense the library is already fully equipped with exception specifications. We can probably do better than this, by being more specific in some cases. Why should we be more specific? With the resolution accepted at Valley Forge (94-0207/N0594) giving teeth to exception specifications, performance can be improved on some architectures if it can be guaranteed that no exception can arise from particular functions. Therefore, we should at least identify those functions deterministic enough that we can know they throw nothing, and declare them so. This certainly includes all the C Library functions, which have never yet produced an exception, but for a few: qsort() is the only holdout I can identify immediately. Others may be discovered while adding "throw()" to their declarations, but it should be obvious (and therefore editorial) which they are. At the other extreme, all the C++ Library templates are very restricted in what can be said about their throw behavior. That behavior depends on what may be thrown by functions provided for the elements on which the library templates are instantiated. Still, many of the remaining functions and classes, and some members of the templates, can reasonably be annotated with throw specifications. In some cases this results in performance improvements, in others it is a documentation aid. For one example, consider locale. Certainly many locale operations may involve complex interactions with user code, but the copy constructor and assignment operator, at least, can always be implemented with no risk of encountering user exceptions. The same may be said for vector::size(). For another example, the vector::at(size_type) is [or should be?] specified to throw out_of_range. When the documented effect of an error is to throw an exception, we should try to guarantee that only those documented may actually occur. Likewise, locale::use<>() may result in a bad_cast exception, but no other. A natural conflict may be perceived here, between a fear that we may be overspecifying implementation, and a desire for complete documentation of behavior. Such conflicts can consume unlimited committee time. Given that the status quo accurately describes all Exception Specifications in the Library 26 Jan 95 page 2 of 2 --------------------------------------- 95-0020/N0620 possible implementations already, however, I hope to proceed by adding specification only where clearly justified by architectural or performance requirements, as suggested above.