Topic: STL and error/exception handling


Author: horstman@sjsumcs.sjsu.edu (Cay Horstmann)
Date: 8 Feb 1995 15:06:19 GMT
Raw View
Jamshid Afshar (jamshid@ses.com) wrote:

: How does the STL handle errors?  For example, will the draft standard
: say what happens if you try to access a vector with an out-of-bounds
: index (e.g., such access causes a particular exception to be thrown)?
: Or, will any such errors simply cause "undefined behavior"?

: My guess is that the STL will simply define any improper use of the
: containers and iterators as causing "undefined behavior", leaving
: compiler and library writers the job of detecting and handling errors
: in their value-added debugging version of the STL.

Your guess is absolutely correct. Plain vanilla STL makes no checks. The
Modena STL implementation optionally checks against array bounds errors,
but not against bum iterators.  In principle, checking against invalid
iterators must surely be possible--after all we are assured by its
boosters that the library is built upon a "solid mathematical foundation".

Cay
horstman@cs.sjsu.edu





Author: jamshid@ses.com (Jamshid Afshar)
Date: 6 Feb 1995 18:27:04 GMT
Raw View
How does the STL handle errors?  For example, will the draft standard
say what happens if you try to access a vector with an out-of-bounds
index (e.g., such access causes a particular exception to be thrown)?
Or, will any such errors simply cause "undefined behavior"?

For example, the RogueWave Tools.h++ library does not detect array
bounds errors in the production version of its library, but its debug
version does and aborts the program.  For other types of errors, if
the cost of error detection is low, they are detected even in the
production version of the library and an RWInternalErr exception is
thrown.

My guess is that the STL will simply define any improper use of the
containers and iterators as causing "undefined behavior", leaving
compiler and library writers the job of detecting and handling errors
in their value-added debugging version of the STL.

Thanks,
Jamshid Afshar
jamshid@ses.com