Exception Specifications in the Library
  ---------------------------------------                26-Jan-95
  by Nathan Myers  <myersn@roguewave.com>               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<T,A>::size().
 
  For another example, the vector<T,A>::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.