Re: When operator>> can throw...
James Kanze <james.kanze@gmail.com> wrote:
Daniel T. wrote:
This is basically what I have now...
class Foo { /* definition irrelevant */ };
istream& operator>>( istream& is, Foo& foo ); // could throw
int main() {
ifstream file( "file.txt" );
Foo foo;
int i = 0;
try {
while ( file >> foo ) {
//process foo;
++i;
}
}
catch ( exception& e ) {
cout << "error at: " << i << '\n';
}
}
The problem I'm having is that op>> could throw.
The question is: what can it throw, and do you want to handle
it? A well written >> will probably only throw something like
bad_alloc, which you generally cannot really handle anyway.
I took the above advice (and Jerry Coffin's) and redesigned my op>> so
that it will not throw.
I'm not sure I understand. Error reporting for istream's is
pretty much standardized: if you encounter a format error, or
there is nothing left to read, you set failbit, a hard read
error, badbit, and while not really an error, anytime you see
EOF, you should set eofbit.
I just read
http://www.unc.edu/depts/case/pgi/pgC++_lib/stdlibug/err_7848.htm and it
seems to indicate that I should not set badbit inside my op>>, rather
that is something the stream itself would do if there is a problem
internal to it.
(from the website cited.)
The flag ios_base::badbit indicates problems with the underlying
stream buffer. These problems could be:
* Memory shortage. There is no memory available to create the
buffer, or the buffer has size zero for other reasons[21], or the
stream cannot allocate memory for its own internal data, as with
iword and pword.
* The underlying stream buffer throws an exception. The stream
buffer might lose its integrity, as in memory shortage, or code
conversion failure, or an unrecoverable read error from the
external device. The stream buffer can indicate this loss of
integrity by throwing an exception, which is caught by the stream
and results in setting the badbit in the stream's state.