exception আর std::expected — ভুল সামলানো

১ · ভুল নকশারই অংশ — কে সামলাবে, আর সে কীভাবে জানবে?

প্রতিটি আসল প্রোগ্রামে কিছু না কিছু ভুল হবেই। ব্যবহারকারী টাকার ঘরে লিখবেন “১২x”, সার্ভারের config ফাইল কেউ মুছে ফেলবেন, নেটওয়ার্ক মাঝপথে কেটে যাবে, ডিস্ক ভরে যাবে। নতুন প্রোগ্রামাররা প্রায়ই ভাবেন, “আগে আসল কাজটা লিখি, ভুল সামলানো পরে যোগ করব।” কিন্তু অভিজ্ঞ প্রকৌশলীরা জানেন, পরে যোগ করা error handling প্রায় সবসময় জোড়াতালি হয়। কারণ ভুল সামলানো আসলে একটি নকশার সিদ্ধান্ত, শুধু কয়েকটি if নয়।

প্রোগ্রামেও ঠিক এমন। যে ফাংশন ভুলটা প্রথম টের পায়, সে প্রায়ই জানে না এখন কী করা উচিত। একটি readFile ফাংশন জানে ফাইলটি নেই, কিন্তু জানে না এটা সার্ভারের নিজের config (তাহলে প্রোগ্রাম চালানোই অর্থহীন), নাকি ব্যবহারকারীর বেছে নেওয়া একটি ছবি (তাহলে “ফাইল পাওয়া যায়নি, আবার বেছে নিন” বললেই চলে)। তাই প্রতিটি ব্যর্থতার জন্য দুটি প্রশ্ন:

উত্তর খুঁজতে আগে ব্যর্থতাগুলোকে তিন ভাগে ভাগ করুন:

খেয়াল করুন, ভাগটা পরিস্থিতির, ভুলের নামের নয়। “ফাইল নেই” একটি ছবি-সম্পাদক অ্যাপে প্রত্যাশিত (ব্যবহারকারী ভুল ফাইল বেছেছেন), আর একটি ব্যাংকের সার্ভারের নিজের config-এর ক্ষেত্রে ব্যতিক্রমী। একই ফাংশনের দুই রকম ব্যবহারকারী থাকলে কখনো দুটি রূপই দেওয়া হয় — C++-এর std::filesystem ঠিক এটাই করে, পরে দেখবেন।

C ভাষায় এই সব কিছুর একটাই উপায় ছিল: রিটার্ন কোড। ফাংশন -1 বা NULL ফেরত দেয়, আর কারণ রাখে global errno-তে। এর দুর্বলতা হলো: উপেক্ষা করা খুব সহজ, ভালো ফল আর ভুলের সংকেত একই চ্যানেলে মেশে (-1 কি বৈধ তাপমাত্রা হতে পারে না?), আর খবর দশ স্তর ওপরে পাঠাতে মাঝের প্রতিটি ফাংশনে হাতে যাচাই লিখতে হয়। C++ এর দুটি উত্তর দিয়েছে: exception (খবর নিজে থেকেই ওপরে ওঠে) আর std::expected (ব্যর্থতা রিটার্ন মানের টাইপেই লেখা থাকে)। দুটিই এই পর্বে।

২ · throw, try, catch — খারাপ খবর ওপরে পাঠানো

Exception-এর ব্যবস্থায় তিনটি অংশ। যে ফাংশন ভুল টের পায়, সে একটি throw দিয়ে একটি exception object “ছোড়ে” — ভুলের বিবরণসহ একটি সাধারণ C++ object. যে অংশ সামলাতে পারে, সে কোডটিকে একটি try block-এ রাখে, আর তার পরে একটি catch লিখে বলে দেয়, কোন টাইপের exception সে ধরবে। মাঝের ফাংশনগুলো? তাদের কিছুই লিখতে হয় না।

throw চলার সঙ্গে সঙ্গে স্বাভাবিক পথ থেমে যায়। প্রোগ্রাম call stack বেয়ে ওপরে উঠতে থাকে — আগে বর্তমান ফাংশনে, তারপর তাকে যে ডেকেছে, তারপর তাকে যে ডেকেছে — যতক্ষণ না মিলে যাওয়ার মতো একটি catch পাওয়া যায়। একটি সার্ভার চালুর তিন স্তরের উদাহরণ দেখুন: startServer ডাকে loadConfig-কে, সে ডাকে readFile-কে, আর ফাইলটি নেই। প্রতিটি ফাংশনে একটি ছোট Guard object আছে, যা ঢোকার আর বের হওয়ার সময় প্রিন্ট করে — যাতে আপনি দেখতে পান কে কখন বিদায় নিচ্ছে:

#include <print>
#include <stdexcept>
#include <string>
struct ConfigError : std::runtime_error {      // nijer exception type
    using std::runtime_error::runtime_error;
};
struct Guard {                                 // RAII: destructor dekhay unwinding
    const char* name;
    explicit Guard(const char* n) : name(n) { std::println("enter {}", name); }
    ~Guard() { std::println("leave {}", name); }
};
void readFile(const std::string& path) {
    Guard g("readFile");
    throw ConfigError("missing file: " + path);
}
void loadConfig()  { Guard g("loadConfig");  readFile("app.conf"); }
void startServer() { Guard g("startServer"); loadConfig(); std::println("server up"); }
int main() {
    try { startServer(); }
    catch (const ConfigError& e) { std::println("caught: {}", e.what()); }
}

ভেতরে ঠিক কী ঘটে, ধাপে ধাপে দেখুন। প্রতিটি ধাপে আগে নিজে অনুমান করুন, তারপর “পরে” চাপুন:

1void readFile(const std::string& path) {2    Guard g("readFile");3    throw ConfigError("missing file: " + path);4}5void loadConfig()  { Guard g("loadConfig");  readFile(...); }6void startServer() { Guard g("startServer"); loadConfig(); ... }7try { startServer(); }8catch (const ConfigError& e) { std::println("caught: {}", e.what()); }

কেন সবসময় const& দিয়ে ধরবেন

catch-এর প্যারামিটার ফাংশনের প্যারামিটারের মতোই। তিনভাবে লেখা যায় — by value, by reference, by const reference. নিয়ম একটাই: by const reference দিয়ে ধরুন।

catch (std::exception e)         { /* ভুল: কপি হয়, আর slicing */ }
catch (const std::exception& e)  { /* ঠিক: আসল object-টিই দেখা যায় */ }

by value ধরলে exception object কপি হয় — অকারণ খরচ। আর বেশি বিপজ্জনক: যদি ছোড়া হয় একটি ConfigError, আর আপনি ধরেন std::exception by value, তাহলে শুধু ভিত্তি-অংশটুকু কপি হয় — বাকি অংশ কেটে বাদ পড়ে। পর্ব ২৪-এ দেখা এই সমস্যার নাম object slicing. তখন e.what() আর আসল বার্তা দেয় না, দেয় শুধু ভিত্তি class-এর সাধারণ লেখা। reference দিয়ে ধরলে কোনো কপি নেই, আর virtual ফাংশন what() আসল টাইপেরটাই চলে। const বলে দেয় যে catch ব্লক exception-টি বদলাবে না।

একাধিক catch থাকলে C++ ওপর থেকে নিচে প্রথম যেটি মেলে, সেটিই বেছে নেয় — সবচেয়ে ভালো মিলটি নয়। তাই নির্দিষ্ট টাইপ আগে, সাধারণ টাইপ পরে লিখুন। catch (const std::exception&) আগে লিখলে নিচের catch (const ConfigError&) কখনো চলবে না; g++ এ নিয়ে একটি warning-ও দেয়।

৩ · std::exception-এর পরিবার — আর নিজের exception class

C++-এ আসলে যেকোনো টাইপ ছোড়া যায় — throw 42; বা throw "error"; পর্যন্ত। কিন্তু তা করবেন না। standard library-র সব exception একটি পরিবারের সদস্য, যার শীর্ষে std::exception (<exception> header). এর একটি virtual ফাংশন আছে, what(), যা ভুলের একটি বর্ণনা দেয়। পরিবারের সবাই এর derived class, তাই একটি মাত্র catch (const std::exception& e) সবাইকে ধরতে পারে। মূল সদস্যরা (<stdexcept> আর <new>-এ):

logic_error আর runtime_error-এর পার্থক্যটা দর্শনের: logic_error বলে “আপনি আমাকে ভুলভাবে ডেকেছেন”, runtime_error বলে “আপনি ঠিকই ডেকেছেন, কিন্তু পৃথিবী সহযোগিতা করেনি।” বাস্তবে অনেক অভিজ্ঞ প্রোগ্রামার মনে করেন, logic_error-এর বেশিরভাগ ক্ষেত্র আসলে বাগ, আর বাগের জন্য exception নয় — assert বা contract ভালো (এ নিয়ে ৮ নম্বর অংশে)। তাই নিজের exception সাধারণত runtime_error থেকে বানানো হয়।

নিজের exception class

নিজের ভুলের জন্য একটি আলাদা টাইপ বানালে ডাকার মানুষ ঠিক সেই ভুলটিকেই আলাদা করে ধরতে পারেন। সবচেয়ে সরল রূপটি আগের কোডেই দেখেছেন: using std::runtime_error::runtime_error; লাইনটি ভিত্তি class-এর constructor ধার করে আনে — পর্ব ২৪-এ দেখা inheriting constructor. বাড়তি তথ্য লাগলে সদস্য যোগ করুন:

class ConfigError : public std::runtime_error {
public:
    ConfigError(const std::string& file, int line)
        : std::runtime_error(file + ":" + std::to_string(line) + ": bad value"),
          line_(line) {}
    int line() const noexcept { return line_; }   // ডাকার মানুষ লাইন নম্বর পায়
private:
    int line_;
};

throw ConfigError("app.conf", 12);   // what() দেয় "app.conf:12: bad value"

কয়েকটি নিয়ম। exception class-কে std::exception-এর পরিবারে রাখুন, যাতে main-এর একটি সাধারণ catch সবাইকে ধরতে পারে। এর কপি করা যেন ব্যর্থ না হয় — runtime_error নিজের বার্তা এমনভাবে রাখে যে কপিতে নতুন মেমরি লাগে না, তাই নিজে বড় std::string সদস্য না রেখে বার্তাটা ভিত্তি class-কে দিন। আর value হিসেবে ছুড়ুন: throw ConfigError(...), কখনো throw new ConfigError(...) নয়। Java বা C#-এর অভ্যাসে লেখা new একটি pointer ছোড়ে, যা const ConfigError& ধরতে পারে না, আর কেউ delete না করলে memory leak.

৪ · Stack unwinding আর RAII — exception কেন নিরাপদ হয়

Exception-এর সবচেয়ে বড় ভয় ছিল: মাঝপথে ফাংশন ছেড়ে গেলে নেওয়া রিসোর্সগুলোর কী হবে? পর্ব ১৭-এ এর উত্তর দেখেছেন — stack unwinding-এর সময় প্রতিটি local object-এর destructor চলে। তাই রিসোর্স যদি RAII object-এ থাকে (std::vector, std::unique_ptr, std::ofstream, std::lock_guard), exception-এর পথেও সব ফেরত যায়। উল্টোটাও সত্য: হাতে new করা মেমরি বা হাতে খোলা ফাইল থাকলে exception সেটিকে leak করবে। exception আর RAII তাই আলাদা বিষয় নয় — একে অপরকে ছাড়া অসম্পূর্ণ। আধুনিক C++ কোড exception-safe হয় মূলত এই কারণে যে তাতে খোলা new/delete প্রায় নেই।

আবার ছোড়া — throw;

কখনো কোনো ফাংশন ভুলটা সামলাতে পারে না, কিন্তু কিছু একটা করে খবরটা ওপরে পাঠাতে চায় — যেমন একটি লগ লিখতে। তখন catch-এর ভেতরে শুধু throw; লিখুন, কোনো নাম ছাড়া। একে বলে rethrow:

try { postToLedger(txn); }
catch (const std::exception& e) {
    log("ledger failed: ", e.what());
    throw;        // ঠিক: একই object, একই আসল টাইপ ওপরে যায়
    // throw e;   // ভুল: নতুন কপি, আর টাইপ কেটে std::exception হয়ে যায়
}

throw e; লিখলে e-এর ঘোষিত টাইপ (std::exception) অনুযায়ী একটি নতুন কপি ছোড়া হয় — আবার সেই slicing. ওপরের catch (const ConfigError&) তখন আর মেলে না। throw; মূল object-টিকেই আবার পাঠায়। (catch-এর বাইরে, কোনো চলমান exception ছাড়া throw; লিখলে প্রোগ্রাম std::terminate হয়।)

catch (...) — শুধু সীমানায়

catch (...) যেকোনো কিছু ধরে, এমনকি std::exception-এর পরিবারের বাইরের টাইপও। তাই এর মধ্যে আপনি জানেন না কী ধরেছেন। এর বৈধ জায়গা মাত্র কয়েকটি — প্রোগ্রামের সীমানা, যেখান দিয়ে exception পার হতে দেওয়া যায় না বা উচিত নয়:

• main-এর একেবারে বাইরের স্তর — শেষবারের মতো একটি বার্তা লিখে ঠিক exit code দিয়ে বেরোনোর জন্য।
• একটি thread-এর প্রথম ফাংশন — thread থেকে exception বেরোলে পুরো প্রোগ্রাম terminate হয় (পর্ব ৪৫)।
• C লাইব্রেরির ডাকা callback — C কোড exception চেনে না, তাই সেখানে exception-কে একটি রিটার্ন কোডে বদলাতে হয়।
• destructor-এর ভেতরে, ব্যর্থ হতে পারে এমন পরিষ্কারের কাজের চারপাশে (নিচে দেখুন)।

এর বাইরে, বিশেষ করে catch (...) {} — খালি ব্লক — প্রায় সবসময় একটি বাগ। এটি ভুলের খবর গিলে ফেলে, আর প্রোগ্রাম আধা-বদলানো ডেটা নিয়ে এমনভাবে চলে যেন কিছুই হয়নি। সপ্তাহ পরে অন্য কোথাও অদ্ভুত ফল দেখা দেয়, আর আসল কারণ খুঁজে পাওয়া প্রায় অসম্ভব। সীমানাতেও catch (...)-এর কাজ হলো লগ করা আর রূপান্তর করা, চুপ করে থাকা নয়।

Destructor থেকে কখনো ছুড়বেন না

stack unwinding চলার সময় destructor-রা চলে। তখন যদি কোনো destructor নিজেও একটি exception ছোড়ে, একসাথে দুটি exception উড়বে — আর C++ সেটা সামলায় না, সরাসরি std::terminate ডাকে। এজন্য C++11 থেকে destructor ডিফল্টভাবে noexcept. কিন্তু পরিষ্কারের কাজও তো ব্যর্থ হতে পারে — যেমন ফাইল বন্ধ করার সময় বাকি লেখা ডিস্কে পাঠাতে গিয়ে ডিস্ক ভরা। রীতিটা হলো: ব্যর্থ-হতে-পারা কাজের জন্য একটি আলাদা ফাংশন দিন, আর destructor শুধু “শেষ চেষ্টা” করুক:

class LogFile {
public:
    void close();                // ব্যর্থ হলে throw — যে জানতে চায়, সে নিজে ডাকবে
    ~LogFile() {                 // noexcept (ডিফল্ট)
        try { if (open_) close(); }
        catch (...) { /* লগ করার চেষ্টা, তারপর চুপ — destructor-এর বাইরে নয় */ }
    }
private:
    bool open_ = false;
};

যে constructor ব্যর্থ হয়

constructor-এর কোনো রিটার্ন মান নেই, তাই রিসোর্স নিতে না পারলে ব্যর্থতা জানানোর সবচেয়ে পরিষ্কার উপায় হলো throw. পর্ব ২১-এ দেখেছেন, এর ফলাফল সুনির্দিষ্ট: object-টি কখনো “তৈরি” হয়নি ধরা হয়, তাই তার নিজের destructor চলে না। কিন্তু ততক্ষণে যে সদস্য আর ভিত্তি-অংশ পুরোপুরি তৈরি হয়ে গেছে, তাদের destructor চলে, উল্টো ক্রমে। এর শিক্ষা: সদস্যগুলোকে RAII টাইপ রাখুন। FILE* আর int* সদস্য রেখে constructor-এর মাঝপথে throw হলে সেগুলো leak করবে, কারণ যে destructor-এ আপনি fclose লিখেছিলেন, সেটি চলবেই না। আর constructor সফল মানেই object ব্যবহারযোগ্য — আলাদা init() ডাকার দরকার নেই।

৫ · Exception safety-র তিন প্রতিশ্রুতি — nothrow, strong, basic

RAII নিশ্চিত করে রিসোর্স leak হবে না। কিন্তু আরেকটি প্রশ্ন থেকে যায়: ব্যর্থতার পর object-গুলোর অবস্থা কী? একটি ফাংশন যদি দুটি হিসাব বদলাতে গিয়ে প্রথমটি বদলে দ্বিতীয়টিতে ব্যর্থ হয়, তাহলে ডেটা একটি অর্ধেক-বদলানো অবস্থায় পড়ে থাকে। এ প্রশ্নের উত্তর দিতে C++ সম্প্রদায় (Dave Abrahams-এর কাজের সূত্রে) তিনটি স্তরের exception safety প্রতিশ্রুতি ব্যবহার করে। প্রতিটি ফাংশন নিজের নথিতে বলে দেয়, সে কোন স্তরের প্রতিশ্রুতি দিচ্ছে:

নিয়মটা এমন: প্রতিটি ফাংশন অন্তত basic দেবে, যেখানে সম্ভব আর অর্থবহ সেখানে strong, আর কয়েকটি মূল ফাংশন (destructor, swap, move) nothrow — কারণ বাকি দুটি প্রতিশ্রুতি এই nothrow ইটগুলোর ওপরেই গাঁথা হয়।

এবার সবচেয়ে চেনা উদাহরণ: রহিম করিমকে ২,০০০ টাকা পাঠাবেন। দুটি ধাপ — রহিমের হিসাব থেকে তোলা, করিমের হিসাবে জমা। ধরুন করিমের wallet-এর একটি সীমা আছে (উদাহরণে ২৫,০০০ টাকা), আর জমা দিতে গেলে সীমা পেরিয়ে যাবে, তাই দ্বিতীয় ধাপ exception ছোড়ে। strong guarantee দিতে হলে প্রথম ধাপটি উল্টে দিতে হবে:

1void transfer(Account& from, Account& to, int amt) {2    from.withdraw(amt);          // ধাপ ১3    try {4        to.deposit(amt);         // ধাপ ২ — ব্যর্থ হতে পারে5    } catch (...) {6        from.refund(amt);        // noexcept — ফিরিয়ে নেওয়া7        throw;                   // একই exception ওপরে8    }9}  // ডাকার জায়গায় catch বার্তা দেখায়

হাতে লেখা rollback ছোট ক্ষেত্রে চলে, কিন্তু ধাপ বাড়লে জটিল হয়ে যায়। সাধারণ, পরিষ্কার কৌশলটি পর্ব ২২-এ দেখেছেন: copy-and-swap. সব কাজ একটি কপির ওপর করুন — যা ব্যর্থ হলে আসলটির গায়ে আঁচড়ও লাগে না — তারপর একটি nothrow swap দিয়ে এক ঝটকায় “commit” করুন:

void Ledger::apply(const Batch& batch) {
    Ledger tmp = *this;              // কপি — ব্যর্থ হলে *this অক্ষত
    for (const auto& t : batch)
        tmp.post(t);                 // যেকোনো ধাপে throw হতে পারে
    std::swap(*this, tmp);           // nothrow (move noexcept হলে) — commit
}

দাম আছে: পুরো খাতার একটি কপি। বড় ডেটায় তাই strong guarantee সবসময় দেওয়া হয় না — standard library-ও সব জায়গায় দেয় না। এটি নকশার একটি সচেতন সিদ্ধান্ত।

৬ · noexcept, std::terminate আর exception-এর আসল খরচ

ফাংশনের পরে noexcept লিখলে আপনি একটি প্রতিশ্রুতি দেন: “এই ফাংশন থেকে কোনো exception বেরোবে না।” এর দুটি লাভ। পাঠক আর compiler দুজনেই জানেন, এই ফাংশন ডাকার পর ব্যর্থতার পথ ভাবতে হবে না — compiler কখনো আরও ছোট কোড বানাতে পারে। আর library (যেমন vector) এই তথ্য দেখে দ্রুততর পথ বেছে নেয়, যা উপরে দেখলেন। noexcept(expr) নামে একটি অপারেটরও আছে, যা compile-এর সময় বলে দেয় একটি এক্সপ্রেশন noexcept কি না — template কোডে এটি কাজে লাগে।

কিন্তু প্রতিশ্রুতি ভাঙলে কী হয়? compiler সাধারণত compile-এর সময় এটা আটকায় না (সবচেয়ে স্পষ্ট ক্ষেত্রে g++ একটি warning দেয়)। চলার সময় exception যদি একটি noexcept ফাংশনের সীমানায় পৌঁছায়, C++ আর catch খোঁজে না — সোজা std::terminate ডাকে, যা ডিফল্টভাবে প্রোগ্রাম বন্ধ করে দেয়। দেখুন:

1void save() noexcept {2    throw std::runtime_error("disk full");3}4int main() {5    try { save(); }6    catch (const std::exception& e) { std::println("caught"); }7}

কোথায় noexcept লিখবেন? destructor-এ এটা আগে থেকেই আছে। move constructor, move assignment আর swap-এ প্রায় সবসময় লিখুন — এগুলো সাধারণত শুধু pointer অদলবদল করে। কিন্তু “শুধু শুধু” সবখানে বসাবেন না: আজ যে ফাংশন ব্যর্থ হয় না, কাল তাতে একটি std::string তৈরি যোগ হলে সেটি bad_alloc ছুড়তে পারে, আর noexcept তখন প্রোগ্রাম বন্ধের ফাঁদ।

খরচের হিসাব — happy path বিনামূল্যে, throw দামি

আধুনিক compiler (Linux-এ GCC আর Clang, Windows-এর 64-bit MSVC) যে পদ্ধতি ব্যবহার করে, তাকে বলে zero-cost exception মডেল। নাম শুনে ভুল বুঝবেন না — এর মানে যতক্ষণ কিছু ছোড়া হয় না, ততক্ষণ প্রায় কোনো খরচ নেই। try-তে ঢুকতে কোনো বাড়তি নির্দেশ চলে না। তার বদলে compiler প্রোগ্রামের পাশে কিছু টেবিল রেখে দেয়: “এই ঠিকানার কোড থেকে exception বেরোলে কোন destructor চালাতে হবে, কোন catch দেখতে হবে।”

দাম দিতে হয় throw-এর মুহূর্তে। তখন runtime exception object-এর জন্য মেমরি নেয়, টেবিলগুলো খুঁজে প্রতিটি frame বুঝে নেয়, প্রতিটি catch-এর টাইপ RTTI দিয়ে মেলায়, আর destructor চালায়। একটি সাধারণ ফাংশন-রিটার্নের তুলনায় এটি বহু গুণ ধীর। এছাড়া টেবিলের জন্য প্রোগ্রামের আকার বাড়ে, আর throw-এর সম্ভাবনা কখনো কখনো optimizer-এর হাত বাঁধে। ফল একটি সরল নিয়ম: যে ঘটনা কালেভদ্রে ঘটে, তার জন্য exception দারুণ; যা প্রায়ই ঘটে (যেমন প্রতি সেকেন্ডে হাজারটি ভুল ইনপুট), তার জন্য রিটার্ন মান।

এই কারণগুলোয় কিছু ক্ষেত্রে পুরো প্রকল্পেই exception বন্ধ রাখা হয়, compiler-এ -fno-exceptions দিয়ে। অনেক গেম ইঞ্জিন এমন করে, কারণ প্রতিটি ফ্রেমের সময় বাঁধা আর অনিশ্চিত খরচ সেখানে অপছন্দের। ছোট embedded যন্ত্রে টেবিলের বাড়তি আকার আর heap-নির্ভরতা সমস্যা। Google-এর C++ style guide বহু বছর ধরে exception ব্যবহার না করার নিয়ম রেখেছে, আর তার একটি বড় কারণ হিসেবে বলেছে তাদের বিশাল পুরোনো কোড, যা exception-কে মাথায় রেখে লেখা হয়নি। এসব প্রকল্পে ভুলের খবর যায় রিটার্ন মানে — আর ঠিক এখানেই std::expected কাজে আসে।

৭ · std::expected — ব্যর্থতা রিটার্ন মানেরই অংশ

প্রত্যাশিত ব্যর্থতার জন্য exception ভারী, আর C-রীতির রিটার্ন কোড উপেক্ষা করা খুব সহজ। C++23 এর মাঝামাঝি একটি সমাধান দিয়েছে: std::expected<T, E> (<expected> header-এ আছে)। এটি একটি বাক্স, যার ভেতরে থাকে হয় একটি সফল মান T, নয়তো একটি ভুলের কারণ E — কখনো দুটিই নয়, কখনো কোনোটি বাদ নয়। ফাংশনের স্বাক্ষর দেখেই ডাকার মানুষ বোঝেন, এটি ব্যর্থ হতে পারে, আর ব্যর্থ হলে কী ধরনের কারণ পাওয়া যাবে।

একটি টাকার অঙ্ক লেখা থেকে পড়ার ফাংশন, সীমা যাচাই আর চার্জ যোগ — তিনটি ধাপের একটি ছোট প্রোগ্রাম দেখুন। এখানে সীমা ১০ থেকে ২৫,০০০ টাকা আর চার্জ ১% ধরা হয়েছে শুধু উদাহরণের জন্য:

#include <charconv>
#include <expected>
#include <print>
#include <string>
#include <string_view>
std::expected<int, std::string> parseAmount(std::string_view s) {   // taka, nahole karon
    int v = 0;
    auto [end, ec] = std::from_chars(s.data(), s.data() + s.size(), v);
    if (ec == std::errc{} && end == s.data() + s.size()) return v;
    return std::unexpected("not a number: " + std::string(s));
}
std::expected<int, std::string> checkLimit(int v) {
    if (v < 10 || v > 25000) return std::unexpected("out of limit: " + std::to_string(v));
    return v;
}
int main() {
    for (std::string_view in : {"500", "12x", "30000"}) {
        auto r = parseAmount(in).and_then(checkLimit).transform([](int v) { return v + v / 100; });
        if (r) std::println("{:>5} -> total {}", in, *r);
        else   std::println("{:>5} -> error: {}", in, r.error());
    }
}

expected থেকে মান বের করার কয়েকটি উপায়, আর প্রতিটির দাম:

auto r = parseAmount(text);   // std::expected<int, std::string>
if (r.has_value()) use(*r);   // বা শুধু if (r) — আগে যাচাই, তারপর *r
int x = r.value_or(0);        // ভুল হলে একটি বিকল্প মান
r.error();                    // শুধু ভুল থাকলেই ডাকবেন, নইলে undefined behavior
r.value();                    // ভুল থাকলে std::bad_expected_access ছোড়ে

খেয়াল করুন, যাচাই না করে *r লিখলে আর ভেতরে ভুল থাকলে সেটা undefined behavior — compiler আপনাকে বাঁচাবে না। value() অন্তত একটি exception ছোড়ে। নিয়ম: আগে যাচাই, তারপর ব্যবহার — অথবা নিচের শৃঙ্খলের পদ্ধতি, যেখানে যাচাই নিজে থেকেই হয়।

শৃঙ্খল — and_then, transform, or_else

প্রোগ্রামের main-এ একটি লাইন লক্ষ করুন: parseAmount(in)-এর পরে .and_then(checkLimit), তারপর .transform(...). প্রতিটি ধাপের পর if না লিখে ধাপগুলো জোড়া হয়েছে। C++23-এ expected-এর এই monadic ফাংশনগুলো আছে:

• and_then(f) — মান থাকলে f(মান) ডাকে; f নিজেও একটি expected ফেরত দেয়, অর্থাৎ নিজেও ব্যর্থ হতে পারে। ভুল থাকলে f ডাকেই না, ভুলটি এগিয়ে দেয়।
• transform(f) — মান থাকলে তাকে বদলায়; f একটি সাধারণ মান ফেরত দেয়, যা ব্যর্থ হয় না (যেমন চার্জ যোগ)।
• or_else(f) — উল্টো দিক: শুধু ভুল থাকলে f(ভুল) ডাকে, যা কখনো ভুল থেকে উদ্ধার করে একটি মান দিতে পারে।
• transform_error(f) — ভুলের টাইপ বদলায়, যেমন নিচের স্তরের ভুলকে ওপরের স্তরের ভাষায়।

এর আসল শক্তি short-circuit: প্রথম ভুলের পর বাকি ধাপগুলো চলে না, ভুলটি শেষ পর্যন্ত বয়ে যায়। দুটি ইনপুট নিয়ে ধাপে ধাপে দেখুন:

1auto r = parseAmount(in)2    .and_then(checkLimit)3    .transform(addFee);4if (r) std::println("total {}", *r);5else   std::println("error: {}", r.error());

std::optional-ও (পরের পর্বে বিস্তারিত) C++23 থেকে একই and_then, transform, or_else পেয়েছে। পার্থক্য: optional শুধু বলে “নেই”, expected বলে “নেই, কারণ এটা”। কারণ যদি ডাকার মানুষের কোনো কাজে না লাগে (যেমন map-এ একটি নাম খোঁজা), optional যথেষ্ট।

std::error_code — এক ঝলক

C++11 থেকে <system_error>-এ আছে std::error_code: একটি সংখ্যা আর একটি “category” (কোন ব্যবস্থার ভুল — অপারেটিং সিস্টেম, নেটওয়ার্ক, নিজের লাইব্রেরি), সাথে মানুষের পড়ার মতো message(). এর সবচেয়ে চেনা ব্যবহার std::filesystem-এ, যেখানে প্রায় প্রতিটি ফাংশনের দুটি রূপ আছে — একটি exception ছোড়ে, অন্যটি error_code-এ ভুল লিখে দেয় (পর্ব ৪৪-এ বিস্তারিত):

std::error_code ec;
auto size = std::filesystem::file_size("data.csv", ec);   // throw করে না
if (ec) std::println("failed: {}", ec.message());

নিজের লাইব্রেরিতে std::expected<T, std::error_code> একটি জনপ্রিয় জোড়া — মান বা একটি মানসম্মত ভুলের কোড।

৮ · কোনটা কখন — সিদ্ধান্তের টেবিল

এখন আপনার হাতে চারটি যন্ত্র: assert, optional, expected আর exception — আর জরুরি অবস্থার জন্য terminate. প্রশ্ন একটাই, প্রথম অংশের দুটি প্রশ্ন: কে সামলাবে, আর কীভাবে জানবে। একটি কাজের টেবিল:

একটি বাস্তব প্রোগ্রামে এগুলো একসাথে থাকে। সার্ভারের main সাধারণত এমন দেখায় — ভেতরে expected আর exception দুটোই, আর সীমানায় একটি পরিষ্কার “শেষ রক্ষা”:

int main() {
    try {
        Config cfg = loadConfig("app.conf");   // না পেলে ConfigError ছোড়ে
        runServer(cfg);   // ভেতরে প্রতিটি অনুরোধ যাচাই হয় std::expected দিয়ে
    } catch (const ConfigError& e) {
        std::println(stderr, "config: {}", e.what());
        return 1;                                // স্পষ্ট বার্তা, স্পষ্ট exit code
    } catch (const std::exception& e) {
        std::println(stderr, "fatal: {}", e.what());
        return 2;
    }
}

৯ · AI-এর যুগে — ভুল সামলানোর ভুল ধরা

AI টুলের লেখা কোডে ভুল সামলানোর অংশটিই সবচেয়ে দুর্বল হয়। কারণ সহজ: অনলাইনের বেশিরভাগ উদাহরণ-কোড শুধু সফল পথ দেখায়, আর যা ভুল সামলায় তার বড় অংশ Java বা পুরোনো C++-এর অভ্যাসে লেখা। দুর্বলতা দেখা দেয় শুধু তখন, যখন সত্যিই কিছু ভুল হয় — ঠিক যখন সবচেয়ে বেশি দরকার। সাধারণ ভুলগুলো:

AI-এর কোডে ভুল-সামলানো যাচাইয়ের চেকলিস্ট

• প্রতিটি catch const reference দিয়ে, আর নির্দিষ্ট টাইপ সাধারণ টাইপের আগে
• কোডে catch (...) খুঁজেছি — প্রতিটি হয় সীমানায় (main, thread, C callback, destructor), নয়তো throw; দিয়ে আবার পাঠায়; কোনোটি খালি নয়
• প্রতিটি throw-এর জন্য বলতে পারি: কে এটা ধরবে, আর সেখানে কী সিদ্ধান্ত হবে
• সাধারণ, প্রায়ই-ঘটা ব্যর্থতা (ভুল ইনপুট, “পাওয়া যায়নি”) exception দিয়ে নয়, রিটার্ন মানে
• প্রতিটি expected ব্যবহারের আগে যাচাই আছে, বা শৃঙ্খল (and_then, transform) দিয়ে লেখা
• exception-এর পথে কোনো খোলা new, fopen বা হাতে নেওয়া lock নেই — সব রিসোর্স RAII-তে
• ভুলের পথ ইচ্ছা করে চালিয়ে দেখেছি (ফাইল মুছে, ভুল ইনপুট দিয়ে) — শুধু সফল পথের পরীক্ষা যথেষ্ট নয়