Re: Will std::bad_alloc be derived from std::system_error?

On Apr 27, 12:33 pm, ?? Tiib <oot...@hot.ee> wrote:


I'm afraid I don't agree with most of this. Surely the only point of
catching std::execption is because you expect all exceptions to be
derived from it? I guess if you're writing code around a library that
uses exceptions not derived from std::exception, this might allow you
to distinguish exceptions originating in the standard library from
those originating in the third party code. But why would you want to
do that?

 std::istream& in = ...;
 try {
   int i; in >> i;
   SomeLibrary::setFoo(i);
 } catch ( std::exception const& ) { /* whatever */ }

.... and now what? You still can't tell whether the exception came
from the istream or a use of the standard library deep within
SomeLibrary. Also, my experience is that libraries that use exception
hierarchies not rooted at std::exception often change them in a later
release so that they are, so in that sense, the code isn't robust.

No, if you want to catch everything, you should just do it. And the
syntax for that is

 catch (...) { /* whatever */ }

Nor do I agree that it's necessarily bad practice to catch all
exceptions without rethrowing. A good example of where this is
standard practice is in writing an istream extractor (that is, an
operator>>) for a user defined type. A good example is found on
p163-4 of 'Standard C++ IOStreams and Locales' by Langer & Kreft.
I've simplified it, below, as much as I can without losing important
detail:

 istream& operator>>( istream& is, date& dat ) {
   if (!is.good()) return is;
   ios_base::iostate err = 0;
   try {
     /* Actually read the date object, setting err if we cannot */
   } catch (...) {
     err |= ios_base::failbit;
     if ( (is.exceptions() & ios_base::badbit) &&
          (err & ios_base::badbit) )
       is.setstate(err); // Will throw ios_base::failure
     else if (is.exception() & ios_base::failbit) {
       try { is.setstate(err); }
       catch ( ios_base::failure const& ) {}
       throw;
     }
   }
   if (err) is.setstate(err); // May throw ios_base::failure
   return is;
 }

So far as I'm aware, although it is clearly complicated, an
implementation along these lines is still regarded as best practice
when implementing istream extractors, and the Standard requires (with
a few exceptions that are subject to defect reports and may be fixed
in C++0x -- I should check) that the extractors in the standard
library are implemented in this way.

Now, the catch (...) block always exits by throwing exception, but not
necessarily by rethrowing the exception that was caught. An exception
(other than bad_alloc which I've glossed over here) thrown reading a
user-defined type is considered equivalent to setting failbit on the
stream. However if something else has already set badbit (which
represents a serious loss of integrity in the iostream) then this
takes precedence and an ios_failure is used to report at loss of
integrity in the stream and the exception from the failure to
correctly read a date is silently dropped.

In my opinion a coding standard (as opposed to a looser coding
guideline) that states that all catch (...) blocks must rethrow is
seriously misguided. Yes, it's useful advice, and more often than
not, rethrowing is the right thing to do; but as this istream example
shows, it isn't always.

Richard Smith

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]