Robust error checking

When you write non-trivial code, do you do error checking on things like printing to cout or cerr with an ostream object? How would you handle it if the << operator fails in the middle of a chain like this for example:

Code:

---

cout << a << b << c << d << endl;

---

I found myself having to overload the >> operator for a somewhat complex class, and there's just so many things that can fail that I don't know where to begin. I thought about using a sentry, but I don't really see the point of doing that since all the istream member functions automatically make use of one either way.

Since the << and >> operators don't throw unless you tell them to so with exceptions(), I don't want my own overloaded operator to do so either. But then my code starts looking very C-ish all of a sudden.

For example, how would you error check get(c), unget() etc. Should I just return if they fail and let the caller deal with whatever mayhem may have been invoked? That seems kinda nasty to do if you've already read some characters from the stream, potentially leading to data loss. But if you can't put them back into the stream what else are you going to do ...

When a stream operation fails, the stream goes into error state and won't do anything further. So you can simply postpone the checking until you're done.

Quote:

---

Originally Posted by Memloop

When you write non-trivial code, do you do error checking on things like printing to cout or cerr with an ostream object? How would you handle it if the << operator fails in the middle of a chain like this for example:

Code:

---

cout << a << b << c << d << endl;

---

I found myself having to overload the >> operator for a somewhat complex class, and there's just so many things that can fail that I don't know where to begin. I thought about using a sentry, but I don't really see the point of doing that since all the istream member functions automatically make use of one either way.

Since the << and >> operators don't throw unless you tell them to so with exceptions(), I don't want my own overloaded operator to do so either. But then my code starts looking very C-ish all of a sudden.

For example, how would you error check get(c), unget() etc. Should I just return if they fail and let the caller deal with whatever mayhem may have been invoked? That seems kinda nasty to do if you've already read some characters from the stream, potentially leading to data loss. But if you can't put them back into the stream what else are you going to do ...

---

Yep. Just bail out. Also, if you're parsing the stream yourself you can signal an error by setting failbit and an eof condition with eofbit (using ios::setstate).

Would this be a good way to handle it?

Code:

---

ios_base::fmtflags fmt_flags = cout.flags();
ios_base::iostate e_flags = cout.exceptions();

try
{
        cout.exceptions(ios_base::badbit);
        cout << "Hello" << endl;
}
catch (ios_base::failure &e)
{
        cerr << e.what() << endl; // Error check this? lol
        cout.flags(fmt_flags);
        cout.exceptions(e_flags);
        // Deal with the error
}

cout.flags(fmt_flags);
cout.exceptions(e_flags);

---

I would prefer to have some RAII going on with the various flags, but I don't feel like writing a guard for that.

Error checking standard IO operations seems like overkill. I'd only bother for file objects or other resources that you deliberately open.

If normal output is failing, the user will certainly see that something is wrong without you needing to report it yourself. Besides, how would you report it? By displaying a message on a stream which is in an error state already?

Unless the error could cause your program to do something catastrophic, I'd ignore it.