Topic: Exception propagation in basic_string extractor


Author: gennaro_prota@yahoo.com (Gennaro Prota)
Date: Sun, 7 Mar 2004 18:03:45 +0000 (UTC)
Raw View
I'm familiar with the way the standard input functions should deal
with exceptions coming from the underlying stream buffer (27.6.1.1/4):
basically the user should see no exceptions unless he requested an
exception for badbit; in that case, however, the stream buffer
exception must be rethrown, rather than a setstate()-generated
ios_base::failure. That means the usual pattern adopted by library
implementations is:

// Warning: untested code
//
template<class charT, class Traits>
std::basic_istream<charT, Traits>& operator>>
          (std::basic_istream<charT, Traits>& is, X& x)
{

  typename basic_istream<charT, Traits>::sentry cerberos(is);

  if(cerberos)
  {
    try {
        //extract characters by calling
        //rdbuf()->sbumpc() or rdbuf()->sgetc()
        //....
    }
    catch(...) {
      bool rethrow = false;
      try {
        is.setstate(std::ios_base::badbit);
      }
      catch(...) {
        rethrow = true;
      }
      if (rethrow)
        throw;
    }
  }

  ...
  return is;
}


Now, my question concerns the extractor for basic_string: it has a
further source of exceptions (see 21.3.7.9/1) in the function
append(), and all the libraries I've looked at follow (basically) the
pattern above, with the append function being called in the uppermost
try block. This implies that a length_error thrown from the string
object (or a bad_alloc) will be treated just like an exception from
the stream buffer, thus setting badbit in is! Of course this is a
non-sense. I think a length error, or an "out of memory" exception
from the string allocator, should be propagated out.

What was the committee intent? Are these implementations simply
broken?


PS: Off-hand, I may imagine that length_error and an allocator
exception could be treated in different ways, for instance with
length_error not setting failbit. But I wanted to know the overall
intent first.


--
Genny.

---
[ 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                       ]