From -3002012031950060837 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,d1fc785202e7cb30 X-Google-Attributes: gidf78e5,public From: kanze@lts.sel.alcatel.de (James Kanze US/ESC 60/3/141 #40763) Subject: Re: Use of standard exception classes Date: 1996/04/15 Message-ID: #1/1 X-Deja-AN: 147640314 references: <9604121530.AA08606@sun132.spd.dsccc.com> <316F646D.552DF1DD@cantrip.org> x-original-date: 15 Apr 1996 19:05:06 GMT apparently-to: std-c++@ncar.UCAR.EDU organization: GABI Software, Sarl. x-auth: PGPMoose V1.1 PGP comp.std.c++ newsgroups: comp.std.c++ originator: austern@isolde.mti.sgi.com In article <316F646D.552DF1DD@cantrip.org> "Nathan Myers " writes: |> > Another developer on our team has asked |> > How can we be sure that ANSI C++ library callbacks work |> > correctly in the face of exceptions? What if ANSI C++ |> > library code catches *our* exception? |> > |> > Is this a problem, or are library functions required to reraise any |> > exceptions thrown by client code? |> I assume that by "library callbacks" s/he means member functions |> invoked by library components? |> Bad things happen if you throw during copy construction or destruction |> of a vector element. Does this imply that `vector< string >' is unsafe. As far as I can tell, it is impossible to write a conforming basic_string that can guarantee never to through a `bad_alloc' during copy. (Even if basic_string normally uses a shared implementation, the semantic constraints on pointer validity after reserve would seem to exclude any sharing of the implementation in this case. So maybe the restriction is that you are not allowed to change the size of `vector< string >' if `reserve' has been called on any of its elements.) |> Don't let it happen. (Yes, I know this is easier |> said than done. Still.) There are lots of things in the library that |> could break if a user object (or even a standard object!) throws during |> a standard function. Probably there are some places where it would be |> safe, but the committee hasn't identified them except in iostreams, where |> it's specified under what circumstances exceptions are caught and rethrown. If I understand what you are saying correctly, we should not use exceptions with the standard library, because it will not be required to be exception safe. And just when everyone has been telling me that I cannot avoid exceptions, because the standard library is throwing them all over the place. (And yes, I know. This latter statement is just what everyone is saying; in fact, there is almost nowhere in the standard library where you cannot avoid exceptions if you want to.) -- 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, itudes et rialisations en logiciel orienti objet -- -- A la recherche d'une activiti dans une region francophone --- [ 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 ]