এরর হ্যান্ডলিং — যেকোনো কিছু ভুল হতে পারে, প্রস্তুত থাকুন

১ · ভুল হবেই — প্রশ্ন হলো তখন প্রোগ্রাম কী করবে

সন্ধ্যা সাতটা, ঢাকার একটি ছোট দোকান। দোকানদার নিজের বানানো একটি হিসাবের প্রোগ্রামে দিনের বিক্রি তুলছেন। হঠাৎ লোডশেডিং। IPS চালু হলো, কম্পিউটার বেঁচে গেল। কিন্তু প্রোগ্রামটি সেই মুহূর্তে ফাইলে লিখছিল। বিদ্যুৎ ফিরলে দেখা গেল — হিসাবের ফাইল অর্ধেক লেখা, প্রোগ্রাম আর খুলছেই না।

যোগ-বিয়োগে কোনো ভুল ছিল না। সমস্যা হলো, প্রোগ্রামটি ধরে নিয়েছিল সবকিছু সবসময় ঠিকঠাক চলবে। বাস্তব পৃথিবী এমন নয়। ডিস্ক ভরে যায়, ফাইল কেউ মুছে ফেলে, নেটওয়ার্ক কেটে যায়, মেমরি ফুরিয়ে যায়, আর ব্যবহারকারী বয়সের ঘরে লেখেন “বাইশ”।

এই প্রস্তুতির নামই error handling. পেশাদার সফটওয়্যারে প্রায়ই দেখা যায়, আসল কাজের কোডের চেয়ে ভুল সামলানোর কোড বেশি। শুনতে অদ্ভুত লাগলেও এটাই স্বাভাবিক — কারণ “সব ঠিক থাকলে” পথ একটাই, কিন্তু “কিছু ভুল হলে” পথ অনেকগুলো।

দুই জাতের ভুল — এবং কেন এদের আলাদা করে চেনা জরুরি

সব ভুল এক রকম নয়। এই পর্বের সবচেয়ে গুরুত্বপূর্ণ ভাগটি এখানেই:

সংক্ষেপে: bug ঠিক করতে হয়; runtime error সামলাতে হয়। অংশ ৬-এ এর জন্য দুটি আলাদা যন্ত্র দেখব।

২ · C-তে exception নেই — ভুলের খবর পাঠানোর উপায়

Java, Python বা C++-এ ভুল হলে একটি exception “ছোড়া” হয়, আর সেটি নিজে থেকেই ফাংশনের পর ফাংশন পেরিয়ে ওপরে উঠে যায়, যতক্ষণ না কেউ তাকে “ধরে”। C-তে এমন কোনো ব্যবস্থা নেই। C-র দর্শন সহজ: ফাংশন তার ফলাফলের সাথেই জানিয়ে দেবে কাজ হলো কি না, আর যে ডেকেছে সে যাচাই করবে।

Standard library আর বাস্তবের C কোডে মূলত চারটি উপায় দেখবেন:

Return code — সবচেয়ে পুরোনো ও সরল উপায়

ফেরত-মান দিয়ে সফলতা বা ব্যর্থতা জানানোকে বলে return code. আপনি এটি আগেই দেখেছেন — main-এর return 0 আসলে একটি return code, যা অপারেটিং সিস্টেম পায় exit status হিসেবে (পর্ব ০৪)। একই চিন্তা আপনার প্রতিটি ফাংশনে চালানো যায়।

সমস্যা একটাই: ফাংশন নিজেই সংখ্যা ফেরত দিলে (যেমন গড় নম্বর) -1 কি “ভুল” নাকি “গড় -1”? তাই পেশাদার কোডে প্রায়ই চতুর্থ উপায় — ফলাফল যায় output parameter-এ (পর্ব ১৮), আর ফেরত-মান শুধু বলে “কাজ হলো কি না”।

errno — “কেন ব্যর্থ হলো” তার খবর

fopen যখন NULL ফেরত দেয়, তখন শুধু জানা যায় “খোলা যায়নি”। কিন্তু কেন? ফাইল নেই? অনুমতি নেই? এই কারণটি জানাতে C-তে আছে errno — <errno.h>-এ ঘোষিত একটি পূর্ণসংখ্যা, যেখানে ব্যর্থ ফাংশন একটি কোড রেখে যায়। যেমন ENOENT মানে “এমন ফাইল বা ফোল্ডার নেই”, EACCES মানে “অনুমতি নেই”, ERANGE মানে “মান সীমার বাইরে”।

এই সংখ্যা মানুষের পড়ার মতো লেখায় বদলাতে দুটি ফাংশন আছে:

• perror("app.conf") — আপনার দেওয়া লেখার পরে কোলন বসিয়ে কারণটি সরাসরি stderr-এ ছাপে।
• strerror(errno) — কারণটি একটি string হিসেবে ফেরত দেয়, যাতে আপনি নিজের মতো করে বার্তা সাজাতে পারেন।

$ ./shop
app.conf: No such file or directory

৩ · ভুল কীভাবে ওপরে ওঠে — আর কে সিদ্ধান্ত নেয়

গার্মেন্টস কারখানার সেলাই লাইনে একজন অপারেটরের সুতা ফুরিয়ে গেল। তিনি নিজে পুরো অর্ডার বাতিল করবেন না — সুপারভাইজারকে জানাবেন। অর্ডার কত জরুরি, গুদামে অন্য সুতা আছে কি না, সেটা সুপারভাইজার জানেন; তাই সিদ্ধান্তও তাঁর।

সফটওয়্যারেও ঠিক তাই। নিচের স্তরের ফাংশন জানে কী ভুল হয়েছে, কিন্তু জানে না সেটার মানে কী। open_file জানে ফাইলটি পাওয়া যায়নি; কিন্তু জানে না ফাইলটি জরুরি নাকি ঐচ্ছিক। এই কারণে ভুলের খবর ধাপে ধাপে ওপরে পাঠানো হয় — একে বলে error propagation. নিচের ডায়াগ্রামে একটি দোকানের প্রোগ্রাম খোলার সময় তার সেটিং ফাইল app.conf খুঁজছে, কিন্তু ফাইলটি নেই। “পরে” চাপুন।

1int open_file(const char *path, FILE **out) {2    FILE *f = fopen(path, "r");3    if (f == NULL) return -1;4    *out = f;  return 0;5}6int read_config(Config *cfg) {7    FILE *f;8    if (open_file("app.conf", &f) != 0) {9        perror("app.conf");10        return -1;11    }12    /* ... settings parse ... */13}14int main(void) {15    if (read_config(&cfg) != 0) {16        fprintf(stderr, "using defaults\n");17        use_defaults(&cfg);18    }19    run_shop(&cfg);

৪ · প্রতিটি ফলাফল যাচাই করুন — চুপচাপ উপেক্ষার দাম

Error handling-এর প্রথম নিয়মটি শুনতে খুব সাধারণ: যে ফাংশন ব্যর্থ হতে পারে, তার ফেরত-মান যাচাই করুন। তবু বাস্তবের অসংখ্য বাগ ঠিক এখান থেকেই আসে। কোন কোন জায়গায় চোখ রাখবেন:

শেষ সারিটি খেয়াল করুন। buffer-এ জমে থাকা লেখা প্রায়ই ডিস্কে যায় fclose-এর সময় (পর্ব ১০-এর buffering মনে করুন), তাই ডিস্ক ভরা থাকলে ব্যর্থতা ধরা পড়ে ঠিক তখনই।

নিরাপদে সংখ্যা পড়া — strtol-এর তিনটি যাচাই

“ব্যবহারকারী সংখ্যার জায়গায় অক্ষর লিখলেন” — এটি সবচেয়ে পরিচিত runtime error. পর্ব ১০-এ দেখেছিলেন, পেশাদার পথ হলো আগে fgets দিয়ে পুরো লাইন পড়া, তারপর যাচাই করে সংখ্যায় বদলানো। এই বদলানোর কাজের সঠিক যন্ত্র strtol. atoi ব্যবহার করবেন না — atoi("abc") চুপচাপ 0 দেয়, ফলে “ভুল ইনপুট” আর “সত্যিকারের শূন্য” আলাদা করা যায় না।

strtol নিজে থেকে ভুল জানায় না; তাকে ঠিকভাবে প্রশ্ন করতে হয়। তিনটি যাচাই লাগে: কোনো অঙ্ক পড়া গেল কি না, শেষে বাড়তি কিছু রয়ে গেল কি না, আর সংখ্যাটি long-এর সীমা ছাড়াল কি না। নিচের কোডটি চালিয়ে দেখুন:

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>

int parse_long(const char *s, long *out) {     /* 0 = OK, else error */
    char *end;  errno = 0;                     /* clear old errors first */
    long v = strtol(s, &end, 10);
    if (end == s || *end != '\0') return 1;   /* no digits, or extra junk */
    if (errno == ERANGE) return 2;             /* too big or too small */
    *out = v;
    return 0;
}

int main(void) {
    const char *in[] = {"42", "abc", "12x", "", "99999999999999999999"};
    const char *why[] = {"OK", "not a number", "out of range"};
    for (int i = 0; i < 5; i++) {
        long n = 0;  int rc = parse_long(in[i], &n);
        printf("\"%s\" -> %s (n = %ld)\n", in[i], why[rc], n);
    }
    return 0;
}

৫ · গুছিয়ে বের হওয়া — goto cleanup

ভুল ধরা হলো অর্ধেক কাজ। বাকি অর্ধেক হলো ভুলের পরে পরিষ্কারভাবে বের হওয়া। ধরুন একটি ফাংশন প্রথমে একটি ফাইল খুলল, তারপর একটি buffer-এর জন্য মেমরি নিল, তারপর আরেকটি টেবিলের জন্য মেমরি চাইল — আর তৃতীয়টি ব্যর্থ হলো। এখন শুধু return -1 লিখলে খোলা ফাইল আর প্রথম buffer চিরকালের জন্য আটকে থাকবে। এটাই memory leak আর resource leak (পর্ব ২০)।

প্রতিটি if-এর ভেতরে আলাদা করে সব ছাড়ার কোড লিখলে কিছু একটা ছাড়তে ভুলে যাওয়া প্রায় নিশ্চিত। সমাধান হলো C-র বহুল প্রচলিত কৌশল goto cleanup. ফাংশনের শেষে cleanup-এর জন্য একটি জায়গা রাখা হয়, আর ভুল হলেই সেখানে লাফ দেওয়া হয়। নিচে Linux kernel-এর ধরনে লেখা একটি উদাহরণ দেখুন:

1int process(const char *path) {2    int rc = -1;3    char *buf = NULL, *tbl = NULL;4    FILE *f = fopen(path, "r");5    if (f == NULL) goto out;6    buf = malloc(4096);7    if (buf == NULL) goto close_file;8    tbl = malloc(100000 * sizeof(Row));9    if (tbl == NULL) goto free_buf;10    rc = do_work(f, buf, tbl);11    free(tbl);12free_buf:13    free(buf);14close_file:15    fclose(f);16out:17    return rc;18}

বড় প্রজেক্টে label-গুলো এভাবে সিঁড়ির মতো সাজানো থাকে। ছোট ফাংশনে আরও সরল একটি রূপ চলে: একটিমাত্র cleanup: label, আর সেখানে সব pointer ছাড়া — কারণ free(NULL) নিরাপদ, কিছুই করে না। নিচের কোডটি একটি কৃত্রিম ব্যর্থতা তৈরি করে দেখায় যে কোন ধাপেই ব্যর্থ হোক, ঠিক ততটুকুই ছাড়া হয় যতটুকু নেওয়া হয়েছিল:

#include <stdio.h>
#include <stdlib.h>

int load_report(int fail_at) {         /* fail_at: which step pretends to fail */
    int rc = -1;  char *file = NULL, *buf = NULL, *table = NULL;
    if ((file  = fail_at == 1 ? NULL : malloc(64)) == NULL) goto cleanup;
    if ((buf   = fail_at == 2 ? NULL : malloc(64)) == NULL) goto cleanup;
    if ((table = fail_at == 3 ? NULL : malloc(64)) == NULL) goto cleanup;
    printf("  all 3 resources ready, work done\n");
    rc = 0;
cleanup:                               /* reverse order; free(NULL) is safe */
    printf("  cleanup: table=%s buf=%s file=%s\n",
           table ? "freed" : "-", buf ? "freed" : "-", file ? "freed" : "-");
    free(table); free(buf); free(file);
    return rc;
}

int main(void) {
    for (int step = 0; step <= 3; step++)
        printf("fail_at=%d -> rc=%d\n", step, load_report(step));
    return 0;
}

৬ · assert নাকি সামলানো? থামবেন, নাকি চলবেন?

assert — নিজের কোডের প্রতি সন্দেহ

<assert.h>-এর assert একটি macro (পর্ব ২৭)। আপনি লেখেন assert(i >= 0 && i < n); — অর্থাৎ “আমার কোড ঠিক থাকলে এটা সবসময় সত্য হবে”। শর্তটি মিথ্যা হলে প্রোগ্রাম সাথে সাথে থেমে যায় এবং ফাইলের নাম, লাইন নম্বর আর শর্তটি ছাপে:

shop: stock.c:42: get_item: Assertion `i >= 0 && i < n' failed.
Aborted (core dumped)

কিন্তু একটি বড় শর্ত আছে। NDEBUG নামের ম্যাক্রো define করে compile করলে (যেমন gcc -DNDEBUG) সব assert পুরোপুরি মুছে যায় — কোডে তাদের কোনো অস্তিত্বই থাকে না। অনেক প্রজেক্ট release build-এ ঠিক এটাই করে। এর দুটি পরিণাম:

• assert দিয়ে কখনো runtime error সামলাবেন না। assert(fopen(...) != NULL) লিখলে release build-এ যাচাইটি হারিয়ে যাবে।
• assert-এর ভেতরে কোনো কাজ রাখবেন না। assert(init_db() == 0) লিখলে release build-এ init_db() ডাকাই হবে না!

Compile-এর সময়েই যা যাচাই করা যায় (যেমন “int অন্তত ৪ বাইট”), তার জন্য আছে static_assert (C11 থেকে) — শর্ত মিথ্যা হলে প্রোগ্রাম তৈরিই হয় না, তাই NDEBUG-এর প্রশ্নও আসে না।

Fail fast বনাম graceful degradation

Runtime error হলে প্রোগ্রামের সামনে দুটি পথ। Fail fast মানে “স্পষ্ট বার্তা দিয়ে এখনই থামো, যাতে ভুল ছড়িয়ে না পড়ে”। Graceful degradation মানে “যা কাজ করছে না তা বাদ দিয়ে, কম সুবিধা নিয়ে হলেও চলতে থাকো”। লোডশেডিংয়ে IPS যেমন এসি চালায় না, কিন্তু লাইট-ফ্যান চালু রাখে — পুরো বাড়ি অন্ধকার হয় না।

কোন পরিস্থিতিতে কোন পথ — তা ঠিক করতে নিচের সিদ্ধান্ত-ছকটি চারটি বাস্তব পরিস্থিতিতে প্রয়োগ করে দেখুন:

char *data = malloc(size);
if (data == NULL) {
    fprintf(stderr, "convert: not enough memory for %zu bytes\n", size);
    return EXIT_FAILURE;     /* ছোট টুল: থামাই নিরাপদ */
}

static int stock_at(const int *stock, int n, int i) {
    assert(i >= 0 && i < n);   /* ডাকছে আমার নিজের কোডই */
    return stock[i];
}

if (read_config(&cfg) != 0) {
    fprintf(stderr, "warning: app.conf missing, using defaults\n");
    use_defaults(&cfg);     /* কম সুবিধায় চলতে থাকো */
}

while (parse_long(line, &age) != 0 || age < 0 || age > 150) {
    printf("Please enter a number between 0 and 150: ");
    if (fgets(line, sizeof line, stdin) == NULL) return 1;
}

৭ · Defensive programming — সীমানায় পাহারা

Defensive programming মানে এমনভাবে কোড লেখা, যেন বাইরের প্রতিটি তথ্যকে সন্দেহের চোখে দেখা হয়। তবে প্রতিটি লাইনে সব কিছু যাচাই করা নয় — তাতে কোড পড়াই কঠিন হয়ে যায়। পেশাদার নিয়মটি হলো সীমানায় পাহারা।

Overflow ঘটার আগেই ধরা

পর্ব ০৫-এ দেখেছিলেন, int-এর সীমা ছাড়ালে কী সর্বনাশ হতে পারে — Ariane 5 রকেটের গল্পটিও সেখানে আছে। আর signed int-এর overflow C-তে undefined behavior, তাই “আগে যোগ করি, পরে দেখি ফল উল্টে গেল কি না” পদ্ধতি কাজ করে না — compiler সেই যাচাইটাই মুছে দিতে পারে। নিয়ম হলো: যোগ করার আগেই হিসাব করুন যোগফল আঁটবে কি না। একটি মোবাইল ওয়ালেটের ব্যালান্সে টাকা যোগের উদাহরণে দেখুন:

1#include <limits.h>   /* INT_MAX = 2147483647 */2int add_balance(int bal, int amount, int *out) {3    if (amount > 0 && bal > INT_MAX - amount)4        return -1;          /* would overflow */5    if (amount < 0 && bal < INT_MIN - amount)6        return -1;          /* would underflow */7    *out = bal + amount;8    return 0;9}

এই হিসাব হাতে লেখা ঝামেলার, আর ভুলও হয়। তাই GCC ও Clang দেয় __builtin_add_overflow(a, b, &result) — যোগফল আঁটলে result-এ রাখে আর false দেয়, না আঁটলে true. আর C23 মানে এসেছে <stdckdint.h>-এর ckd_add(&result, a, b) — একই কাজ, এবার মানসম্মতভাবে। নতুন কোডে এগুলোই ব্যবহার করুন।

ভালো error message — কাকে, কী, কোথায়

ভুলের বার্তা লেখা হয় দুজন মানুষের জন্য: যিনি প্রোগ্রাম ব্যবহার করছেন, আর পরে যিনি সমস্যা খুঁজবেন। নিচের তুলনাটি দেখুন:

তিনটি অভ্যাস রাখুন। এক, ভুলের বার্তা যাবে stderr-এ (পর্ব ১০), যাতে আউটপুট ফাইলে পাঠালেও বার্তাটি স্ক্রিনে থাকে। দুই, ব্যর্থ হলে শূন্য নয় এমন exit status (EXIT_FAILURE), যাতে script বা CI বোঝে কাজটি হয়নি। তিন, দীর্ঘ সময় চলা প্রোগ্রামে logging — ঘটনা ও ভুল সময়সহ ফাইলে লিখে রাখা, DEBUG, INFO, WARN, ERROR মাত্রায় ভাগ করে। রাত তিনটায় সার্ভার বিকল হলে সকালে হাতে থাকবে শুধু এই লগ।

৮ · বাস্তবের শিক্ষা — যখন ভুল সামলানো হয়নি

Error handling শুধু বইয়ের তত্ত্ব নয়। ইতিহাসে এমন দুটি ঘটনা দেখুন, যা আজও সফটওয়্যার প্রকৌশলের পাঠ্যক্রমে পড়ানো হয়।

এই পর্বের প্রায় সব শিক্ষাই এখানে: overflow আগে যাচাই না করা, অর্থহীন error message, আর জীবন-মরণের প্রশ্নে fail safe না হওয়া — অবস্থা অস্পষ্ট হলেই বিকিরণ বন্ধ রাখা উচিত ছিল।

এখানে শিক্ষা কিছুটা ভিন্ন। কোনো একটি ফাংশনের ফেরত-মান উপেক্ষার চেয়ে বড় ব্যাপার হলো সিস্টেম-স্তরের অপ্রস্তুতি: সব সার্ভারে একই কোড পৌঁছেছে কি না সেই যাচাই ছিল না, পুরোনো অব্যবহৃত কোড মুছে ফেলা হয়নি, আর ভুল ধরা পড়লে দ্রুত সব থামানোর (fail fast-এর) স্পষ্ট ব্যবস্থা ছিল না। Error handling তাই শুধু একটি if নয় — এটি পুরো সিস্টেম নকশার অংশ।

৯ · AI-এর যুগে এরর হ্যান্ডলিং

AI-কে “একটি ফাইল পড়ে গড় বের করার C প্রোগ্রাম লেখো” বললে সাধারণত যে কোড আসে, তা সব ঠিক থাকলে চমৎকার চলে। কিন্তু AI শেখে মূলত উদাহরণ-কোড থেকে, যেখানে জায়গা বাঁচাতে error handling প্রায়ই বাদ থাকে। তাই ভুলের পথগুলোই সবচেয়ে দুর্বল — আর সাধারণ পরীক্ষায় তা ধরা পড়ে না, কারণ তখন ফাইলও থাকে, মেমরিও থাকে।

AI সাধারণত যেসব ভুল করে

AI-এর লেখা কোড হাতে পেলে — ভুলের পথের চেকলিস্ট

• প্রতিটি fopen, malloc, realloc, scanf, fgets-এর ফেরত-মান যাচাই হচ্ছে
• নিচের স্তরের কোনো ফাংশনে exit() নেই; ভুল ফেরত-মান হয়ে ওপরে যাচ্ছে
• প্রতিটি ভুলের পথে যা যা নেওয়া হয়েছিল তা ছাড়া হচ্ছে (Valgrind বা AddressSanitizer দিয়ে ভুলের পথ চালিয়ে দেখেছি)
• বার্তাগুলো stderr-এ যাচ্ছে, আর পড়ে বোঝা যায় কী হয়েছে
• ব্যর্থ হলে প্রোগ্রাম শূন্য নয় এমন exit status দিচ্ছে
• ইচ্ছে করে ভুল ঘটিয়ে দেখেছি: ফাইল মুছে, খালি ফাইল দিয়ে, অক্ষর টাইপ করে, বিশাল সংখ্যা দিয়ে
• assert শুধু নিজের কোডের নিয়ম পাহারা দিচ্ছে — ব্যবহারকারীর ইনপুট বা ফাইল নয়