Error Handling during I/O

Programming Language & Its Applications — Virtual Functions and File Handling, NEC licence examination syllabus (Nepal Engineering Council).

Error Handling During I/O

Four state bits that tell you what went wrong — and why an unchecked stream fails silently instead of loudly.

🌍 Where this lives: silent I/O failure is one of the great sources of production bugs. A config file path with a typo, a disk that filled up mid-write, a user typing "abc" where a number was expected — in every case a C++ stream keeps running and quietly does nothing. That is how a report ends up full of zeros and nobody notices for a week. Every robust program checks stream state; every fragile one assumes success. Search "errno vs exceptions vs error codes" to see the wider debate about how software should report failure, and "std::expected C++23" for where C++ is heading.

The four state bits

Every stream carries a state word with four flags: goodbit 0 everything fine, no error eofbit 1 end of file was REACHED failbit 2 a logical error — a read failed, a conversion failed, or the open failed badbit 4 a serious error — the stream is unusable (hardware failure, corrupted buffer) QUERY FUNCTIONS: s.good() true if NO bit is set — safe to continue s.eof() true if eofbit set s.fail() true if failbit OR badbit set s.bad() true if badbit set s.rdstate() returns the raw bits s.clear() resets to goodbit s.clear(state) sets a specific state if (s) ≡ !s.fail() ← the idiomatic test if (!s) ≡ s.fail() IMPORTANT RELATIONSHIPS: · eof() alone does NOT mean failure — you can reach the end successfully · reading PAST the end sets BOTH eofbit and failbit · failbit is recoverable with clear(); badbit usually is not · once ANY error bit is set, ALL further operations are no-ops until you clear() That last rule is the one that bites. A failed stream stays failed. Every subsequent >> silently does nothing.

states.cpp

#include <iostream>
#include <sstream>
#include <fstream>
#include <string>

void report(const std::string &tag, const std::ios &s) {
    std::cout << "  " << tag
              << "  good=" << s.good()
              << " eof=" << s.eof()
              << " fail=" << s.fail()
              << " bad=" << s.bad() << "\n";
}

int main() {
    std::cout << std::boolalpha;

    /* 1. a normal successful read */
    { std::istringstream s("42");
      int n; s >> n;
      report("read 42 :", s); }

    /* 2. reading a number where text is — CONVERSION failure */
    { std::istringstream s("abc");
      int n = -1; s >> n;
      report("read abc:", s);
      std::cout << "    n is still " << n
                << " — the variable was NOT touched\n"; }

    /* 3. reading past the end */
    { std::istringstream s("7");
      int a, b; s >> a;
      report("after 7 :", s);
      s >> b;
      report("past end:", s); }

    /* 4. a file that does not exist */
    { std::ifstream f("no_such_file_here.txt");
      report("bad open:", f); }

    /* 5. recovery: clear() then carry on */
    { std::istringstream s("abc 99");
      int n;
      s >> n;
      std::cout << "  before clear: fail=" << s.fail() << "\n";
      s.clear();
      std::string junk; s >> junk;      /* consume "abc" */
      s >> n;
      std::cout << "  after clear+skip: n=" << n
                << " fail=" << s.fail() << "\n"; }
    return 0;
}
Output:
  read 42 :  good=true eof=false fail=false bad=false
  read abc:  good=false eof=false fail=true bad=false
    n is still -1 — the variable was NOT touched
  after 7 :  good=false eof=true fail=false bad=false
  past end:  good=false eof=true fail=true bad=false
  bad open:  good=false eof=false fail=true bad=false
  before clear: fail=true
  after clear+skip: n=99 fail=false

Four things the output proves: 1. A FAILED READ LEAVES THE VARIABLE ALONE. Reading "abc" into an int failed and n kept its old value −1. Since C++11 a failed >> also writes 0 to the variable, but the safe habit is: initialise before reading, and CHECK. 2. eof WITHOUT fail is normal. After reading "7" the stream hit the end but the read SUCCEEDED — eof=true, fail=false. So `while (!s.eof())` is the wrong loop condition (see below). 3. Reading PAST the end sets both eof and fail. 4. failbit is RECOVERABLE. clear() resets the state, but you must also REMOVE the offending input — otherwise the next >> hits the same "abc" and fails again, forever. That is the classic infinite input loop.

The eof() loop bug

WRONG — processes the last item twice: while (!in.eof()) { in >> value; /* may FAIL on the last attempt */ process(value); /* but we process anyway */ } Why: eofbit is set only AFTER a read attempts to go past the end. On the final iteration, >> fails, value is unchanged, and process() runs again on stale data. RIGHT — test the READ itself: while (in >> value) { /* the stream converts to bool */ process(value); } `in >> value` returns the stream; the stream's explicit operator bool is !fail(). So the loop stops the moment a read fails, for ANY reason. Same for lines: WRONG: while (!in.eof()) { getline(in, line); use(line); } RIGHT: while (getline(in, line)) { use(line); } DISTINGUISHING WHY the loop ended: while (in >> value) { ... } if (in.eof()) cout << "reached the end normally"; else if (in.fail()) cout << "malformed data"; else if (in.bad()) cout << "hardware/stream failure"; That three-way check is what a robust parser does — it must tell "finished" from "broken".

eof_bug.cpp

#include <iostream>
#include <sstream>

int main() {
    /* WRONG loop */
    {
        std::istringstream s("10 20 30");
        int v = 0, count = 0;
        std::cout << "  WRONG: ";
        while (!s.eof()) { s >> v; std::cout << v << " "; count++; }
        std::cout << " -> " << count << " iterations\n";
    }

    /* RIGHT loop */
    {
        std::istringstream s("10 20 30");
        int v = 0, count = 0;
        std::cout << "  RIGHT: ";
        while (s >> v) { std::cout << v << " "; count++; }
        std::cout << " -> " << count << " iterations\n";
    }

    /* diagnosing WHY a parse stopped */
    {
        std::istringstream s("10 20 oops 40");
        int v, sum = 0, n = 0;
        while (s >> v) { sum += v; n++; }
        std::cout << "  parsed " << n << " values, sum=" << sum << " — ";
        if (s.eof())       std::cout << "clean end\n";
        else if (s.bad())  std::cout << "stream broken\n";
        else if (s.fail()) std::cout << "MALFORMED DATA found\n";
    }
    return 0;
}
Output:
  WRONG: 10 20 30 30  -> 4 iterations
  RIGHT: 10 20 30  -> 3 iterations
  parsed 2 values, sum=30 — MALFORMED DATA found

The wrong loop printed 30 TWICE and ran 4 times for 3 values. Trace it: iter 1: eof false → read 10, print 10 iter 2: eof false → read 20, print 20 iter 3: eof false → read 30, print 30 (the stream has consumed everything but eofbit is NOT yet set — nothing has tried to read past the end) iter 4: eof STILL false → read FAILS, v unchanged at 30, print 30 again. NOW eofbit is set. iter 5: eof true → loop exits That off-by-one duplicate is the signature of this bug. If you ever see the last record of a file processed twice, this is why. And the third case shows the diagnosis working: it summed 10 + 20 = 30, stopped at "oops", and correctly reported malformed data rather than a clean end.

The rule generalises beyond C++: test the operation, not a predicted state. while (in >> v) asks "did this read work?", which is the actual question. while (!in.eof()) asks "do I expect the next read to work?", which is a guess — and guesses about I/O are wrong at exactly the boundary you care about.

Worked example — validated input that cannot loop forever

validate.cpp

#include <iostream>
#include <sstream>
#include <limits>
#include <string>

/* Reads an int in [lo,hi] from any istream, rejecting
   garbage without ever spinning forever. */
bool readInt(std::istream &in, int &out, int lo, int hi) {
    for (;;) {
        if (in >> out) {
            if (out >= lo && out <= hi) return true;
            std::cout << "    out of range, try again\n";
        } else {
            /* distinguish "broken input" from "no more input" */
            if (in.eof() || in.bad()) return false;
            in.clear();                       /* reset failbit */
            in.ignore(std::numeric_limits<std::streamsize>::max(),
                      '\n');                  /* DISCARD the junk */
            std::cout << "    not a number, try again\n";
        }
    }
}

int main() {
    /* simulated user input: junk, out of range, then valid */
    std::istringstream fake("abc\n999\n-5\n42\n");
    int v;
    std::cout << "  reading a value in [1,100]:\n";
    if (readInt(fake, v, 1, 100))
        std::cout << "  accepted " << v << "\n";
    else
        std::cout << "  input exhausted\n";

    /* and the exhaustion path */
    std::istringstream empty("xyz\n");
    std::cout << "  second attempt:\n";
    if (!readInt(empty, v, 1, 100))
        std::cout << "  input exhausted, gave up cleanly\n";
    return 0;
}
Output:
  reading a value in [1,100]:
    not a number, try again
    out of range, try again
    out of range, try again
  accepted 42
  second attempt:
    not a number, try again
  input exhausted, gave up cleanly

Both halves of the fix are mandatory: clear() resets failbit so the stream will work again ignore() REMOVES the offending characters Do only clear() and "abc" stays in the buffer, so the next >> fails on the same input — an infinite loop that pegs the CPU at 100%. Do only ignore() and the stream is still in a fail state, so ignore() itself is a no-op. You need both, in that order. The eof/bad check before clearing is what makes the function terminate: if there is genuinely no more input, retrying is pointless and it returns false instead of looping. This exact function — clear, ignore, retry, with an exhaustion guard — is the standard robust-input idiom in C++. Worth memorising.

Exceptions on streams

Streams do NOT throw by default. You can ask them to: std::ifstream f("data.txt"); f.exceptions(std::ios::failbit | std::ios::badbit); try { f >> value; /* now throws on failure */ } catch (const std::ios_base::failure &e) { std::cerr << e.what(); } WHY IT IS OFF BY DEFAULT: reaching end-of-file is normal, not exceptional, and it sets failbit. So enabling failbit exceptions makes every ordinary read loop throw at the end, which you then have to catch — usually more awkward than checking the state. The practical middle ground most codebases use: f.exceptions(std::ios::badbit); /* throw on real errors only, check failbit normally */ WRITE ERRORS deserve special attention. An open for writing succeeds even if the disk is nearly full; the failure appears later, during flush or close: std::ofstream out("big.dat"); out << hugeAmountOfData; out.close(); if (!out) std::cerr << "the write FAILED"; ← check HERE If you rely on the destructor to close, you never get the chance to check — the destructor cannot report an error. That is the one case where an explicit close() matters.

🌍 Go further: the four-state-bit design is showing its age, and C++ is moving on. C++23 added std::expected<T, E>, which makes a function return either a value or an error that the caller cannot ignore — the compiler warns if you drop it. Rust built its whole error story on the same idea with Result<T, E> and the ? operator, and Go returns explicit error values everywhere. All three are reactions to exactly the problem on this page: a failure you can accidentally not notice. Search "std::expected C++23" and "Rust Result error handling".

💡 Exam angle: list the four state bits (goodbit, eofbit, failbit, badbit) with what sets each, and the query functions good(), eof(), fail(), bad(), clear(). The while (!eof()) bug — last item processed twice — is a favourite trace question; show both the wrong and right loops. Know that a failed stream ignores all further operations until clear(), and that recovering from bad input needs both clear() and ignore(). Mention that streams do not throw unless you call exceptions().

Syllabus points

Stream state; error detection

Create a free account to tick topics off, take notes as you read, watch the video lessons and get a day-by-day study plan built around your exam date.