Exception with Arguments

Programming Language & Its Applications — Generic Programming and Exception Handling, NEC licence examination syllabus (Nepal Engineering Council).

Exception with Arguments

Throwing objects that carry data — so the handler can do more than print a message.

🌍 Where this lives: a useful error tells you what to do next, and that needs data. HTTP libraries throw exceptions carrying the status code so you can distinguish a 404 (give up) from a 503 (retry later). Database drivers carry the SQL state and the failing query. Validation frameworks carry the field name and the rejected value so a web form can highlight the exact input. A bare message string forces the handler to parse text to recover information the thrower already had. Search "custom exception class design" — the guidance across languages is identical: carry structured data, not just prose.

Any type can be thrown

throw 42; /* an int */ throw 3.14; /* a double */ throw "literal"; /* a const char* */ throw std::string("text"); /* a std::string */ throw MyError(404, "not found"); /* your own class */ throw std::runtime_error("msg"); /* a standard type */ THE THROWN OBJECT IS COPIED. When you write void f() { MyError e(404, "not found"); throw e; /* e is COPIED out */ } /* the local e is destroyed */ the exception object outlives f's frame because a copy was made. That is why the type must be COPYABLE. WHAT NEVER TO THROW: · a POINTER to a local throw &localObject; ✗ dangling immediately · a pointer to heap memory throw new MyError(); ✗ who deletes it? The handler must, and if it rethrows or is a catch(...), it leaks. catch (MyError *e) { ... delete e; } is a pattern to avoid. · anything expensive to copy, unless you must WHAT TO THROW: an object BY VALUE, deriving from std::exception, carrying exactly the data a handler needs. throw ValidationError("age", -5, 0, 120); DESIGN CHECKLIST for a custom exception: 1. derive publicly from std::exception (or a subclass) 2. override what() — or pass a message to runtime_error's constructor, which stores it for you 3. add accessors for the structured data 4. make the copy constructor noexcept if you can 5. keep it cheap to copy — no heavy members 6. never let its constructor throw

custom_exceptions.cpp

#include <iostream>
#include <stdexcept>
#include <string>
#include <sstream>
#include <vector>

/* Approach 1: derive from runtime_error, which stores the
   message for you, and ADD structured data. */
class HttpError : public std::runtime_error {
    int         status;
    std::string url;
public:
    HttpError(int code, std::string u)
        : std::runtime_error("HTTP " + std::to_string(code)
                             + " for " + u),
          status(code), url(std::move(u)) {}

    int  code() const noexcept { return status; }
    const std::string& target() const noexcept { return url; }

    /* the data enables DECISIONS, not just messages */
    bool retryable() const noexcept {
        return status == 429 || (status >= 500 && status < 600);
    }
};

/* Approach 2: derive from std::exception and manage the
   message yourself by overriding what(). */
class ValidationError : public std::exception {
    std::string field, message;
    double      value, lo, hi;
public:
    ValidationError(std::string f, double v, double a, double b)
        : field(std::move(f)), value(v), lo(a), hi(b) {
        std::ostringstream os;
        os << "field '" << field << "' = " << value
           << " outside [" << lo << ", " << hi << "]";
        message = os.str();
    }
    /* what() must be noexcept and must NOT allocate —
       that is why the string is built in the constructor */
    const char* what() const noexcept override {
        return message.c_str();
    }
    const std::string& fieldName() const noexcept { return field; }
    double got() const noexcept { return value; }
    double min() const noexcept { return lo; }
    double max() const noexcept { return hi; }
};

void fetch(const std::string &url, int simulate) {
    if (simulate != 200) throw HttpError(simulate, url);
    std::cout << "      200 OK  " << url << "\n";
}

void validateAge(double a) {
    if (a < 0 || a > 120) throw ValidationError("age", a, 0, 120);
    std::cout << "      age " << a << " accepted\n";
}

int main() {
    /* the handler uses code() to decide POLICY */
    for (int status : {200, 404, 503, 429}) {
        std::cout << "  fetch with status " << status << ":\n";
        try { fetch("/api/students", status); }
        catch (const HttpError &e) {
            std::cout << "      " << e.what() << "\n";
            std::cout << "      -> "
                      << (e.retryable() ? "RETRY later"
                                        : "give up, permanent")
                      << "  (code " << e.code() << ")\n";
        }
    }

    /* the handler uses the field name and bounds */
    for (double a : {22.0, -5.0, 200.0}) {
        std::cout << "  validateAge(" << a << "):\n";
        try { validateAge(a); }
        catch (const ValidationError &e) {
            std::cout << "      " << e.what() << "\n";
            std::cout << "      -> highlight input '"
                      << e.fieldName() << "', suggest "
                      << e.min() << ".." << e.max() << "\n";
        }
    }
    return 0;
}
Output:
  fetch with status 200:
      200 OK  /api/students
  fetch with status 404:
      HTTP 404 for /api/students
      -> give up, permanent  (code 404)
  fetch with status 503:
      HTTP 503 for /api/students
      -> RETRY later  (code 503)
  fetch with status 429:
      HTTP 429 for /api/students
      -> RETRY later  (code 429)
  validateAge(22):
      age 22 accepted
  validateAge(-5):
      field 'age' = -5 outside [0, 120]
      -> highlight input 'age', suggest 0..120
  validateAge(200):
      field 'age' = 200 outside [0, 120]
      -> highlight input 'age', suggest 0..120

The handlers did something no message string allows: retryable() decided policy from the CODE. 404 is permanent, 503 and 429 are transient. With only a message, the handler would have to parse "HTTP 404 for ..." with string searching — fragile, and it breaks when someone rewords the message. fieldName() and min()/max() let a UI highlight the exact input and show the valid range. That information existed at the throw site and would have been thrown away by a plain runtime_error. TWO IMPLEMENTATION DETAILS WORTH COPYING: 1. ValidationError builds its message in the CONSTRUCTOR, not in what(). what() is declared noexcept, so it must not allocate — building a string inside it could throw std::bad_alloc while an exception is already in flight, which calls std::terminate. 2. HttpError delegates the message to runtime_error's constructor. That is less code and gets a correct what() for free. Prefer it unless you need a computed message. Both are marked noexcept on their accessors. An exception's own methods failing during error handling is the worst possible time for a failure.

Note the asymmetry: what() is noexcept and returns const char*, not std::string. Both constraints exist because what() is called while the program is already in a failure state — allocating memory or throwing at that moment could turn a recoverable error into a hard termination.

Worked example — an exception hierarchy for one subsystem

hierarchy_design.cpp

#include <iostream>
#include <stdexcept>
#include <string>
#include <vector>
#include <sstream>

/* ---- a base for everything this subsystem throws ---- */
class BankError : public std::runtime_error {
    std::string accountId;
public:
    BankError(const std::string &msg, std::string acc)
        : std::runtime_error(msg), accountId(std::move(acc)) {}
    const std::string& account() const noexcept { return accountId; }
};

/* ---- specific failures, each with its own data ---- */
class InsufficientFunds : public BankError {
    double balance, requested;
public:
    InsufficientFunds(const std::string &acc, double bal, double req)
        : BankError(build(acc, bal, req), acc),
          balance(bal), requested(req) {}
    double available() const noexcept { return balance; }
    double needed()    const noexcept { return requested; }
    double shortfall() const noexcept { return requested - balance; }
private:
    static std::string build(const std::string &a, double b, double r) {
        std::ostringstream os;
        os << "account " << a << ": balance Rs " << b
           << " cannot cover Rs " << r;
        return os.str();
    }
};

class AccountFrozen : public BankError {
    std::string reason;
public:
    AccountFrozen(const std::string &acc, std::string why)
        : BankError("account " + acc + " is frozen: " + why, acc),
          reason(std::move(why)) {}
    const std::string& why() const noexcept { return reason; }
};

class DailyLimitExceeded : public BankError {
    double limit, attempted, alreadyUsed;
public:
    DailyLimitExceeded(const std::string &acc, double lim,
                       double att, double used)
        : BankError("daily limit exceeded on " + acc, acc),
          limit(lim), attempted(att), alreadyUsed(used) {}
    double remaining() const noexcept { return limit - alreadyUsed; }
    double attemptedAmount() const noexcept { return attempted; }
};

/* ---- the operation ---- */
struct Account {
    std::string id;
    double      balance;
    bool        frozen;
    std::string freezeReason;
    double      withdrawnToday;
};

const double DAILY_LIMIT = 25000.0;

void withdraw(Account &a, double amount) {
    if (a.frozen)
        throw AccountFrozen(a.id, a.freezeReason);
    if (amount > a.balance)
        throw InsufficientFunds(a.id, a.balance, amount);
    if (a.withdrawnToday + amount > DAILY_LIMIT)
        throw DailyLimitExceeded(a.id, DAILY_LIMIT, amount,
                                 a.withdrawnToday);
    a.balance        -= amount;
    a.withdrawnToday += amount;
    std::cout << "      OK: Rs " << amount
              << " withdrawn, balance Rs " << a.balance << "\n";
}

int main() {
    Account a1{"AC-1001", 50000, false, "",     0};
    Account a2{"AC-1002",  3000, false, "",     0};
    Account a3{"AC-1003", 90000, true,  "KYC pending", 0};
    Account a4{"AC-1004", 80000, false, "", 20000};

    struct Req { Account *acc; double amt; };
    std::vector<Req> reqs = {
        {&a1, 15000}, {&a2, 5000}, {&a3, 1000}, {&a4, 10000}
    };

    for (auto &r : reqs) {
        std::cout << "  withdraw Rs " << r.amt << " from "
                  << r.acc->id << ":\n";
        try { withdraw(*r.acc, r.amt); }
        catch (const InsufficientFunds &e) {
            std::cout << "      " << e.what() << "\n"
                      << "      -> short by Rs " << e.shortfall()
                      << ", offer overdraft\n";
        }
        catch (const AccountFrozen &e) {
            std::cout << "      " << e.what() << "\n"
                      << "      -> route to compliance ("
                      << e.why() << ")\n";
        }
        catch (const DailyLimitExceeded &e) {
            std::cout << "      " << e.what() << "\n"
                      << "      -> Rs " << e.remaining()
                      << " left today; suggest splitting\n";
        }
        catch (const BankError &e) {
            std::cout << "      unclassified on account "
                      << e.account() << ": " << e.what() << "\n";
        }
    }
    return 0;
}
Output:
  withdraw Rs 15000 from AC-1001:
      OK: Rs 15000 withdrawn, balance Rs 35000
  withdraw Rs 5000 from AC-1002:
      account AC-1002: balance Rs 3000 cannot cover Rs 5000
      -> short by Rs 2000, offer overdraft
  withdraw Rs 1000 from AC-1003:
      account AC-1003 is frozen: KYC pending
      -> route to compliance (KYC pending)
  withdraw Rs 10000 from AC-1004:
      daily limit exceeded on AC-1004
      -> Rs 5000 left today; suggest splitting

Verifying the computed values: AC-1001: 50000 − 15000 = 35000 ✔ AC-1002: shortfall = 5000 − 3000 = 2000 ✔ AC-1004: remaining = 25000 − 20000 = 5000, and the attempted 10000 exceeds it ✔ THE DESIGN, and why it is worth the extra classes: · a COMMON BASE (BankError) carrying the account id, so one catch(const BankError&) can log every subsystem failure uniformly · SPECIFIC TYPES for each failure, each carrying exactly the data its handler needs · DERIVED DATA computed by the exception itself — shortfall() and remaining() are arithmetic the handler would otherwise have to repeat Every handler produced a DIFFERENT, actionable response: offer an overdraft, route to compliance, suggest splitting the transaction. None of those decisions is possible from a message string alone. Compare the alternative: throw std::runtime_error("withdrawal failed"); The caller can log it and nothing else.

🌍 Go further: C++11 gave a standard mechanism for exactly this pattern: std::system_error carries a std::error_code — a portable integer plus a category — so <filesystem> and networking code can report OS errors that you compare against named constants rather than parsing text. It also underpins std::error_condition for grouping equivalent errors across platforms. Search "std::error_code vs exceptions"; the design lets one API report failures either way, which is why <filesystem> functions come in throwing and non-throwing overloads.

💡 Exam angle: state that any copyable type can be thrown and that the thrown object is copied, so throwing a pointer to a local is a dangling-pointer bug and throwing new MyError() leaks. Write a custom exception class deriving from std::exception (or runtime_error) with an overridden what() and accessors for its data — that is the standard question. Know that what() must be noexcept and returns const char*, so build the message in the constructor. The strongest answer explains why structured data beats a message: it lets the handler make decisions.

Syllabus points

Passing arguments to exceptions

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.