[ moderator's note: Forwarded to C++ Committee. -sdc ]

Paragraph 3 under clause 17.4.4.8, Restrictions on Exception Handling,
[lib.res.on.exception.handling] states that "Any other functions
defined in the C++ Standard Library that do not have an
exception-specification may throw implementation-defined exceptions
unless otherwise specified."  This statement is followed by a
reference to footnote 178 at the bottom of that page which states,
apparently in reference to the C++ Standard Library, that "Library
implementations are encouraged (but not required) to report errors by
throwing exceptions from (or derived from) the standard exceptions."

These statements appear to be in direct contradiction to clause
18.6.1[lib.exception], which states "The class exception defines the
base class for the types of objects thrown as exceptions by the C++
Standard library components ...".

Is this inconsistent?

Randy.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

rmaddox@isicns.com (Randy Maddox) wrote in message
news:<8c8b368d.0207220839.78e8cbbf@posting.google.com>...

> Paragraph 3 under clause 17.4.4.8, Restrictions on Exception Handling,
> [lib.res.on.exception.handling] states that "Any other functions
> defined in the C++ Standard Library that do not have an
> exception-specification may throw implementation-defined exceptions
> unless otherwise specified."  This statement is followed by a
> reference to footnote 178 at the bottom of that page which states,
> apparently in reference to the C++ Standard Library, that "Library
> implementations are encouraged (but not required) to report errors by
> throwing exceptions from (or derived from) the standard exceptions."

> These statements appear to be in direct contradiction to clause
> 18.6.1[lib.exception], which states "The class exception defines the
> base class for the types of objects thrown as exceptions by the C++
> Standard library components ...".

> Is this inconsistent?

Sort of.  What 18.6.1 should probably say is that the class exception
defines the base class for the types of objects thrown in the cases
where the standard requires an exception.

The real problem, of course, is the liberty granted the implementation
under 17.4.4.8.  In practice, I don't know of any implementation which
takes advantage of it, but if it were taken literally, it would make the
standard library totally unusable in robust code.  In practice, I think
that there are only three possible cases:

  - No error occurs.  All of the implementations I know fulfill the
    contract and return normally.  I really don't want to give the
    implementation the liberty to do otherwise.

  - An checked error occurs.  Most of the implementations I know throw
    the exception specified by the standard.  (In the case of running
    out of memory, a few do something funny, rather than throwing
    bad_alloc.)  Again, the standard specifies a way of reporting the
    error, and no quality implementation will do anything else.

  - An unchecked error occurs.  As far as I can tell, this always
    results in undefined behavior.  I would encourage implementations to
    throw an exception in such cases, but they don't need any special
    language in the standard in order to be able to do so; undefined
    behavior means that they can do anything (including throw an
    exception from a function specified as throw()).

So I really would prefer to see the language in 17.4.4.8 dropped.  I can
understand the committee's desire to leave a loophole here.  After all,
at the time of standardization, a large part of the standard library was
really just speculation, and no one really knew if it could be
implemented or not.  But today, with a few exceptions (e.g. fpos), we
know roughly what is or is not possible, and the loophole is no longer
needed.

Or is it?  On systems with very tight memory, perhaps all of the
constructors for std::vector always throw a sorry_not_implemented
exception.  And throwing some implementation defined exception is
probably the only conforming implementation for some of the
functionality of fpos, since the standard defined behavior is
mathematically impossible to achieve.  Still, most implementations I
know of prefer to implement something useful, albeit not conform with
the standard, rather than throwing an exception, which would probably
make the class unusable.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]