"David Rohacek" <david.rohacek@natinst.com> wrote:
>J. Kanze <kanze@gabi-soft.fr> wrote in article
>> 1. I cannot use the standard library if any of my code throws
>> exceptions, and

>I've been following this thread with interest, but I don't see this
>particular point.  Can you please briefly support this postulate?

I believe the issue is that if a container class is templated on a
type that may throw exceptions in its default constructor, copy
constructor, or assignment operator, the container classes aren't
required to behave reasonably if an exception is thrown. Thus they may
leak memory or, even worse, may be in an inconsistent state after such
an exception is thrown.

Am I missing anything?

Andrew Bell
abell@mindspring.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <3252DB5A.FC36332@cantrip.org>,
Nathan Myers  <ncm@cantrip.org> wrote:
>James Kanze US/ESC 60/3/141 #40763 remarks:
>
>> It's worth noting, too, that the only exception that most of the
>> standard library can throw is bad_alloc.
>
>This is not correct.  The Draft imposes no restrictions on what
>exceptions may be thrown by functions in the standard library.
>
Indeed several other standard exceptions exist and are thrown
(see for example the member functions of the string classes).
This discussion seems to go off topic.
May be bad_alloc occurs often and may be the only acceptable
reaction for that is endign the programm.
BUT have in mind:
 - others exceptions (even user defined from user types)
   may occur and may have reactions that don't result in
   an end of the program.
 - For those exceptions I would like to have a defined state in my programm.
   With the current standard draft i have not.
 - I don't wan't to miss exception handling.
   (It is very poor to argue: "to use STL don't use EH").
Conclusion:
 - haven a defined behavior for exceptions in STL is
   absolutelt necessary (IMO).

Could any member of the standardization comittee explain,
why exception safety is NOT part of the STL
(even not in the standard)?

Best regards
--
Nico                             address: BREDEX GmbH, Nicolai Josuttis
email:   nico@bredex.de                   Fallersleber-Tor-Wall 23
phone:   +49 531 24330-0                  D-38100 Braunschweig
fax:     +49 531 24330-99                 Germany


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Nico Josuttis <nico@bredex.de> writes:

> In article <3252DB5A.FC36332@cantrip.org>,
> Nathan Myers  <ncm@cantrip.org> wrote:
> >James Kanze US/ESC 60/3/141 #40763 remarks:
> >
> >> It's worth noting, too, that the only exception that most of the
> >> standard library can throw is bad_alloc.
> >
> >This is not correct.  The Draft imposes no restrictions on what
> >exceptions may be thrown by functions in the standard library.
> >
> Indeed several other standard exceptions exist and are thrown
> (see for example the member functions of the string classes).

There are several cases where the standard library is *required* to
throw and exception.  My interpretation was, and still is, that a
library function can in fact only throw an exception on failure; there
are not that many cases of failure: off hand, if the library response is
not explicitly documented (most of the time), the only cases that occur
to me are insufficient memory, and a violation of constraints by the
user which leads to undefined behavior.

> This discussion seems to go off topic.

There are, effectively, two (or more) different questions being
discussed in this thread.

> May be bad_alloc occurs often and may be the only acceptable
> reaction for that is endign the programm.
> BUT have in mind:
>  - others exceptions (even user defined from user types)
>    may occur and may have reactions that don't result in
>    an end of the program.
>  - For those exceptions I would like to have a defined state in my programm.
>    With the current standard draft i have not.
>  - I don't wan't to miss exception handling.
>    (It is very poor to argue: "to use STL don't use EH").

This is, however, the conclusion that one is forced to adopt today.
I'll admit that I wouldn't miss exceptions very much, but: I don't
usually have the choice.  The standard library does throw them in a few
specific cases.  The current situation basically boils down to:

1. I cannot use the standard library if any of my code throws
exceptions, and

2. The standard library may throw exceptions,

Thus: I cannot use the standard library if I use the standard library.

> Conclusion:
>  - haven a defined behavior for exceptions in STL is
>    absolutelt necessary (IMO).

Given the above reasoning, it should be obvious that I concur.

> Could any member of the standardization comittee explain,
> why exception safety is NOT part of the STL
> (even not in the standard)?

A good guess might be that this sort of thing cannot be done by simply
waving a magic wand.  The committee counts on volunteer labor, and if no
one volunteers to tackle this problem, it won't get solved.

--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

J. Kanze <kanze@gabi-soft.fr> wrote in article
<m3n2xkxxmf.fsf@gabi-soft.fr>...
> This is, however, the conclusion that one is forced to adopt today.
> I'll admit that I wouldn't miss exceptions very much, but: I don't
> usually have the choice.  The standard library does throw them in a few
> specific cases.  The current situation basically boils down to:
>
> 1. I cannot use the standard library if any of my code throws
> exceptions, and

I've been following this thread with interest, but I don't see this
particular point.
Can you please briefly support this postulate?

Thanks,
David Rohacek
david.rohacek@natinst.com

** These rantings are my own... **
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:

>It is worth noting that the C standard makes no claims here either.  I
>imagine that most implementations of qsort will use malloc to obtain a
>swap area; is an implementation which never frees nor reuses this memory
>conforming?  Or is this a question of quality of implementation?  Would
>exception safety in the library be a similar issue?  (Even if so, some
>sort of guidelines in the standard would be nice.  It is generally
>accepted that a memory leak is an error, and most people would not
>hesitate to state that an implementation of qsort that does not free
>allocated memory is an error.  There is considerably less concensus as
>to what one can/should count on with regards to exception safety.)

I'm pretty sure that the standard states that functions from the C
standard library may not throw exceptions, except when they use a user
defined callback function that throws the exception.  Therefore, qsort
may only throw an exception if the compare function you provided it
throws an exception.





---
Robert Mashlan  R2M Software  rmashlan@r2m.com
Internet Resources for Windows Developers http://www.r2m.com/windev/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

rmashlan@r2m.com (Robert Mashlan) writes:

> kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) wrote:
>
> >It is worth noting that the C standard makes no claims here either.  I
> >imagine that most implementations of qsort will use malloc to obtain a
> >swap area; is an implementation which never frees nor reuses this memory
> >conforming?  Or is this a question of quality of implementation?  Would
> >exception safety in the library be a similar issue?  (Even if so, some
> >sort of guidelines in the standard would be nice.  It is generally
> >accepted that a memory leak is an error, and most people would not
> >hesitate to state that an implementation of qsort that does not free
> >allocated memory is an error.  There is considerably less concensus as
> >to what one can/should count on with regards to exception safety.)
>
> I'm pretty sure that the standard states that functions from the C
> standard library may not throw exceptions, except when they use a user
> defined callback function that throws the exception.  Therefore, qsort
> may only throw an exception if the compare function you provided it
> throws an exception.

Totally agreed, but does this have to do with what I said?

--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Nathan Myers <ncm@cantrip.org> writes:

> James Kanze US/ESC 60/3/141 #40763 remarks:
>
> > It's worth noting, too, that the only exception that most of the
> > standard library can throw is bad_alloc.
>
> This is not correct.  The Draft imposes no restrictions on what
> exceptions may be thrown by functions in the standard library.

Good point.  I hadn't thought of it from this point of view.

Does this mean, for example, that vector::operator[] can have exactly
the same implementation as vector::at()?  (If I understand correctly,
the only difference is that vector::at() is guaranteed to throw an
exception on a bounds error, whereas for vector::operator[], this is
undefined behavior.  And I think I just answered my own question.)

--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Nathan Myers <ncm@cantrip.org> writes:

> James Kanze US/ESC 60/3/141 #40763 remarks:
>
> > It's worth noting, too, that the only exception that most of the
> > standard library can throw is bad_alloc.
>
> This is not correct.  The Draft imposes no restrictions on what
> exceptions may be thrown by functions in the standard library.

And a second follow-up: I think it does, indirectly.  It specifies the
semantics of the functions; if the semantics do not include throwing an
exception (perhaps indirectly, e.g.: the function is allowed to allocate
memory), I would argue that the function may not throw an exception.
(This is basically the same arguement one would use to claim that an
implementation of memcpy that formatted the hard disk was not
conforming.  There are certainly no words in the C standard that
expressedly forbid memcpy from formatting the disk, but I think most
people would consider this behavior a bug, and not a feature.)

--
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze writes:
> Nathan Myers writes:
> > James Kanze writes:
> > > It's worth noting, too, that the only exception that most of the
> > > standard library can throw is bad_alloc.
> >
> > This is not correct.  The Draft imposes no restrictions on what
> > exceptions may be thrown by functions in the standard library.
>
> And a second follow-up: I think it does, indirectly.  It specifies the
> semantics of the functions; if the semantics do not include throwing an
> exception (perhaps indirectly, e.g.: the function is allowed to allocate
> memory), I would argue that the function may not throw an exception.

If a function does allocate memory then it can throw an object of any
type, since it may call a new_handler.

If remarks on exception safety are added to the standard, then they
must acknowledge this, and any required throw( ) clauses must take this
into account as well (essentially, anything that allocates memory cannot
have a throw( ) clause).  For example:

    std::operator new( size_t )
        ? must be equivalent to ::operator new( size_t ) ?

    std::ios::ios( )
        Allocates memory using std::operator new( size_t ).
        If std::operator new( size_t ) exits by throwing the
        object x, then std::ios::ios( ) will exit by throwing
        the object x.  [Furthermore, any resources obtained through
        earlier, successful calls to std::operator new( size_t )
        will be released via calls to std::operator delete( void * )
        before std::ios::ios( ) exits in this way.]

        Does not throw an object for any other reason.

Is this level of detail reasonable?  Is there a way to generalize
this so that it only needs to be said once?

Regards,
Garth A. Dickie

Garth A. Dickie
dickie@elastic.avid.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article fsf@gabi-soft.fr, kanze@gabi-soft.fr (J. Kanze) writes:
>Nathan Myers <ncm@cantrip.org> writes:
>
>>
>> This is not correct.  The Draft imposes no restrictions on what
>> exceptions may be thrown by functions in the standard library.
>
>And a second follow-up: I think it does, indirectly.  It specifies the
>semantics of the functions; if the semantics do not include throwing an
>exception (perhaps indirectly, e.g.: the function is allowed to allocate
>memory), I would argue that the function may not throw an exception.

But the draft standard says otherwise:

==================================================
17.3.4.8 Restrictions on exception handling [lib.res.on.exception.handling]

Any of the functions defined in the C++ Standard library can report a failure
by throwing an exception of the type(s) described in their Throws: paragraph
and/or their exception   specification (15.4). An implementation may strengthen
the exception   specification for a function by removing listed exceptions.160)

None of the functions from the Standard C library shall report an error by
throwing an exception,161) unless it calls a program   supplied function that
throws an exception.162)

Any of the functions defined in the C++ Standard library that do not have an exception   specification may throw implementation   defined exceptions.163) An
implementation may strengthen this implicit exception   specification by adding
an explicit one.164)
 __________________
160) That is, an implementation of the function will have an explicit
 exception   specification that lists fewer exceptions than those specified
 in this International Standard. It may not, however, change the types of
 exceptions listed in the exception   specficiation from those specified,
 nor add others.
161) That is, the C library functions all have a throw() exception   specification.
 This allows implementations to make performance optimizations based on the
 absence of exceptions at runtime.
162) The functions qsort() and bsearch() (25.4) meet this condition.
163) In particular, they can report a failure to allocate storage by throwing an
 exception of type bad_alloc, or a class derived from bad_alloc (18.4.2.1).
 Library implementations are encouraged (but not required) to report errors
 by throwing exceptions from (or derived from) the standard exception
 classes (18.4.2.1, 18.6, 19.1).
164) That is, an implementation may provide an explicit exception   specification
 that defines the subset of any exceptions thrown by that function.
 This implies that the implementation may list implementation   defined
 types in such an exception   specification.
==================================================

Most C++ library functions have no exception specification. The draft
standard explicitly allows implementations of those functions to
throw any exception (which is what the lack of a specification means
anyway). Implementations can add exception specifications to any such
library functions, or tighten up the specifications that the standard
decrees. Such enhancements cannot break code that conforms to the standard.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <dickie-0310962206300001@elasticdial4.avid.com>
dickie@fantasia.avid.com (Garth A. Dickie) writes:

|> James Kanze writes:
|> > Nathan Myers writes:
|> > > James Kanze writes:
|> > > > It's worth noting, too, that the only exception that most of the
|> > > > standard library can throw is bad_alloc.
|> > >
|> > > This is not correct.  The Draft imposes no restrictions on what
|> > > exceptions may be thrown by functions in the standard library.
|> >
|> > And a second follow-up: I think it does, indirectly.  It specifies the
|> > semantics of the functions; if the semantics do not include throwing an
|> > exception (perhaps indirectly, e.g.: the function is allowed to allocate
|> > memory), I would argue that the function may not throw an exception.

|> If a function does allocate memory then it can throw an object of any
|> type, since it may call a new_handler.

The (draft) standard places significant limits on new_handler.  It may
either return, having made more storage available, terminate program
execution (calling either exit or abort), or throw bad_alloc or a class
derived from bad_alloc.

|> If remarks on exception safety are added to the standard, then they
|> must acknowledge this, and any required throw( ) clauses must take this
|> into account as well (essentially, anything that allocates memory cannot
|> have a throw( ) clause).

There are two separate problems concerning exceptions:

1. What exceptions can a given function throw?  Much of the library is,
in fact, templates, and what it can throw will obviously depend on the
class for which it is instantiated.  There is not, in C++, any way
within the language to specify that a given template function will throw
only one of the exceptions in a given list, OR an exception thrown from
a given list of functions concerning the instantiation type.  It would
be nice if this were specified in the standard, even if the
specification cannot be part of the header file, but my impression is
that this is not going to occur (probably for want of time).

As a simple example, a reasonable (I think) specification for the
constructor of a vector is that it may throw either bad_alloc, or any
exception thrown by the copy constructor of the instantiation type.
(This IS a simple example.  If the specifications for all functions were
this simple, it is possible that the committee would be able to find
time.)

2. What does the function do if a function called by it throws an
exception, i.e.: in how far is the standard library exception safe?

Again, a simple example: in vector::push_back, the copy constructor of
the instantiation type throws an exception.  In this case, I would
expect that the vector remains unchanged, and that on destruction of the
vector, no memory remains allocated.  (As above: if all of the functions
were this simple, I think we'd have a complete specification.)

In reality, I'd be pleasantly surprised if we got 1, but we can live
without it.  Without 2, on the other hand, the standard library is
unusable in many projects.

|> For example:

|>     std::operator new( size_t )
|>         ? must be equivalent to ::operator new( size_t ) ?

|>     std::ios::ios( )
|>         Allocates memory using std::operator new( size_t ).
|>         If std::operator new( size_t ) exits by throwing the
|>         object x, then std::ios::ios( ) will exit by throwing
|>         the object x.  [Furthermore, any resources obtained through
|>         earlier, successful calls to std::operator new( size_t )
|>         will be released via calls to std::operator delete( void * )
|>         before std::ios::ios( ) exits in this way.]

|>         Does not throw an object for any other reason.

|> Is this level of detail reasonable?

In article <199610041847.LAA06008@taumet.eng.sun.com>
clamage@Eng.Sun.COM (Steve Clamage) writes:

|> In article fsf@gabi-soft.fr, kanze@gabi-soft.fr (J. Kanze) writes:
|> >Nathan Myers <ncm@cantrip.org> writes:
|> >
|> >>
|> >> This is not correct.  The Draft imposes no restrictions on what
|> >> exceptions may be thrown by functions in the standard library.
|> >
|> >And a second follow-up: I think it does, indirectly.  It specifies the
|> >semantics of the functions; if the semantics do not include throwing an
|> >exception (perhaps indirectly, e.g.: the function is allowed to allocate
|> >memory), I would argue that the function may not throw an exception.

|> But the draft standard says otherwise:

So I see:-).

|> ==================================================
|> 17.3.4.8 Restrictions on exception handling [lib.res.on.exception.handling]

|> Any of the functions defined in the C++ Standard library can report a failure
|> by throwing an exception of the type(s) described in their Throws: paragraph
|> and/or their exception   specification (15.4). An implementation may strengthen
|> the exception   specification for a function by removing listed exceptions.160)

This is not really significantly different from what I meant to say
(rather than what I said).  The implicit guarantee is that the function
will not throw an exception gratuiously.  IMHO, this is covered by the
"report a failure".  In the absense of failure, no exception.

This leads to the question of what is failure, or rather what functions
are guaranteed not to fail.  I would argue, for example, that
vector::operator[]() cannot fail when given a valid index.  (And since
it is explicitly undefined behavior to give it an unvalid index,
obviously, the implementation can throw an exception in this case, even
if its throw specification says otherwise.)

|> None of the functions from the Standard C library shall report an error by
|> throwing an exception,161) unless it calls a program   supplied function that
|> throws an exception.162)

|> Any of the functions defined in the C++ Standard library that do not have an exception   specification may throw implementation   defined exceptions.163) An
|> implementation may strengthen this implicit exception   specification by adding
|> an explicit one.164)

I'm not sure I like this.  For obvious reasons, none of the template
functions will have exception-specifications.  So I have no guarantees
whatsoever as to what they will throw.

1. I would certainly prefer some sort of guarantee that destructors do
not throw exceptions unless the exception comes from user code.  I'd
also like to see this guarantee extended to const functions, but I
believe that this would require some explicit exceptions (string::c_str,
etc.).  Without the guarantee for destructors, it becomes very
difficult, if not impossible, to *portably* use the standard library in
"robust" applications (applications which run forever, and must stay up,
no matter what).

2. How can I intelligently handle exceptions if I don't know what
exception(s) I might receive?  While less critical than being sure that
the library code itself is "exception safe" (for some definition of
"exception safe"), it would seem reasonable to limit the *types* of
exceptions they may throw themselves.  (Requiring derivation from one of
the standard exceptions would be a good start, for example.)

In some ways, point 2 is more important than the rest.  I can easily
argue that exception safety within the library will be handled by
"quality of implementation"; the better implementations will do things
correctly.  I could also argue that it is at least partially implicit: I
believe that one could argue that as long as the user strictly conforms
to the interface, the library is required to "work"; to work, it must
never enter a state where an object cannot be deleted, it must
(eventually) free all memory allocated by it, etc., etc.

It is worth noting that the C standard makes no claims here either.  I
imagine that most implementations of qsort will use malloc to obtain a
swap area; is an implementation which never frees nor reuses this memory
conforming?  Or is this a question of quality of implementation?  Would
exception safety in the library be a similar issue?  (Even if so, some
sort of guidelines in the standard would be nice.  It is generally
accepted that a memory leak is an error, and most people would not
hesitate to state that an implementation of qsort that does not free
allocated memory is an error.  There is considerably less concensus as
to what one can/should count on with regards to exception safety.)
--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils,    tudes et r   alisations en logiciel orient    objet --
                -- A la recherche d'une activit    dans une region francophone



[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

James Kanze US/ESC 60/3/141 #40763 remarks:

> It's worth noting, too, that the only exception that most of the
> standard library can throw is bad_alloc.

This is not correct.  The Draft imposes no restrictions on what
exceptions may be thrown by functions in the standard library.

Nathan Myers
ncm@cantrip.org
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]