error সামলানো — throw, try/catch, custom error আর cause

১ · error কী — প্রোগ্রামের “আর এগোতে পারছি না” বার্তা

একটি দৃশ্য দিয়ে শুরু করি। নুসরাত একটি অনলাইন দোকানের চেকআউট পাতা বানিয়েছেন। একদিন এক ক্রেতা অর্ডার দিলেন, বাটন চাপলেন — কিছুই হলো না। পাতা স্থির, কোনো বার্তা নেই। ক্রেতা আবার চাপলেন, তারপর বিরক্ত হয়ে অন্য দোকানে চলে গেলেন। পরে নুসরাত DevTools খুলে দেখলেন console-এ লাল লেখা:

Uncaught TypeError: Cannot read properties of undefined (reading 'phone')
    at buildInvoice (checkout.js:41:28)
    at placeOrder (checkout.js:17:5)

ক্রেতা ফোন নম্বরের ঘর ফাঁকা রেখেছিলেন, কোড ধরে নিয়েছিল ঘরটি সবসময় থাকবে। আসল সমস্যা কিন্তু শুধু ফাঁকা ঘর নয়। সমস্যা হলো প্রোগ্রামটি ভুলটা কাউকে জানায়নি — না ক্রেতাকে (“ফোন নম্বর দিন”), না নুসরাতকে (কোনো log বা রিপোর্ট নেই)। এই পর্বের পুরো বিষয়টাই এখানে: ভুল হবেই; প্রশ্ন হলো ভুলটা কোথায় ধরা পড়বে, কে জানবে, আর তারপর কী হবে।

সব ভুল এক রকম নয় — চার ধরনের সমস্যা

• Syntax error — চালানোর আগে। JavaScript engine কোড চালানোর আগে পুরো script পড়ে (parse করে)। একটি বন্ধনী বাদ পড়লে SyntaxError: Unexpected token '{' — আর সেই script-এর একটি লাইনও চলে না (পর্ব ০৫)। এগুলো try/catch দিয়ে ধরা যায় না, কারণ try/catch নিজেই তো তখনো চালু হয়নি; ধরা পড়ে editor, ESLint বা প্রথমবার চালানোর সময়ই।
• Runtime exception — চলার সময়। ব্যাকরণ ঠিক, কিন্তু চলতে চলতে এমন কিছু করতে বলা হলো যা অসম্ভব: undefined-এর property পড়া, যা function নয় তাকে ডাকা, অজানা নাম ব্যবহার। এগুলোই exception — try/catch এদের জন্য।
• Logic bug — কেউ টের পায় না। ছাড়ের হিসাবে +-এর জায়গায় -, লুপ এক ঘর কম। কোনো error আসে না, প্রোগ্রাম আনন্দে ভুল ফল দেখায়। সবচেয়ে বিপজ্জনক এগুলোই; ধরতে লাগে টেস্ট (পর্ব ৪৮), assert আর নিজের যাচাই।

আরেকটি ভাগ পেশাদার জগতে খুব কাজের — ভুলটা কার? Operational error হলো কোড ঠিক থাকা সত্ত্বেও বাইরের কারণে ব্যর্থতা: ইন্টারনেট চলে গেল, সার্ভার ৫০৩ দিল, ব্যবহারকারী ভুল তারিখ লিখলেন, ব্যালান্স কম। এগুলো প্রত্যাশিত — আগে থেকে ভেবে সামলাতে হয় (আবার চেষ্টা, স্পষ্ট বার্তা, বিকল্প পথ)। Programmer error হলো কোডের নিজের বাগ: ভুল টাইপের argument পাঠানো, undefined ধরে না রাখা। এগুলো চলার সময় “সামলানো” যায় না — catch করে চেপে রাখলে বাগ শুধু লুকায়; সমাধান কোড ঠিক করা। Node.js-জগতে এই ভাগটি জনপ্রিয় করেছিল Joyent-এর একটি পরিচিত নির্দেশিকা, আর আজও ভালো error handling-এর প্রথম প্রশ্ন এটাই: “এটা কি প্রত্যাশিত ব্যর্থতা, নাকি বাগ?”

২ · Error object আর built-in error-এর পরিবার

JavaScript যখন নিজে কোনো ভুল ধরে, সে একটি Error object বানিয়ে ছোড়ে। এই object-এর তিনটি জিনিস প্রায় সবসময় পাবেন:

• name — error-এর ধরন, যেমন "TypeError". কোডে সিদ্ধান্ত নেওয়ার জন্য এটিই নির্ভরযোগ্য।
• message — মানুষের পড়ার বার্তা, যেমন "o.pay is not a function". Engine-ভেদে আর সংস্করণভেদে বদলায়, তাই কোডে বার্তা মিলিয়ে সিদ্ধান্ত নেবেন না।
• stack — error কোথায় তৈরি হলো আর কোন কোন function পার হয়ে এলো, তার তালিকা (stack trace). মজার তথ্য: stack আজও ECMAScript মানদণ্ডের অংশ নয় — সব বড় engine দেয়, কিন্তু নিজের নিজের আকারে (ভাবনার প্রশ্ন ৩)।

Edge বা Chrome-এ (V8 engine) একটি stack দেখতে মোটামুটি এরকম — ওপরের লাইনে name: message, তারপর প্রতিটি লাইনে একটি function, ফাইল, লাইন আর কলাম:

RangeError: সীমা ৫০০ টাকা
    at c (app.js:2:27)
    at b (app.js:6:16)
    at a (app.js:11:5)

Firefox একই তথ্য লেখে c@app.js:2:27 আকারে। পড়ার নিয়ম সহজ: ওপরের লাইন হলো ভুলের জায়গা, নিচের দিকে গেলে “কে ডেকেছিল”. প্রায়ই ওপরের কয়েকটি লাইন library-র ভেতরের; নিচে নামতে নামতে প্রথম যে লাইনে নিজের ফাইলের নাম পাবেন, সাধারণত সেখান থেকেই খোঁজা শুরু করবেন।

কোন error কখন আসে

নিচের বার্তাগুলো Edge-এ (V8) চালিয়ে নেওয়া; Node.js-এও একই engine, তাই প্রায় এক। Firefox বা Safari-র বার্তা ভিন্ন ভাষায় লেখা হয়, কিন্তু name একই থাকে।

সবগুলোই সাধারণ Error-এর “সন্তান” — new TypeError("x") instanceof Error হলো true. এর বাইরে ব্রাউজারের নিজস্ব DOMException আছে (পর্ব ১৯-এর DataCloneError, fetch বাতিল করলে AbortError), আর Node.js-এর error-এ থাকে বাড়তি code field, যেমন ফাইল না পেলে err.code === "ENOENT" (পর্ব ৪৯)।

৩ · throw আর stack unwinding — error কোন পথে ওঠে

Engine নিজে error ছোড়ে, আর আপনিও ছুড়তে পারেন — throw statement দিয়ে। নিয়ম ভাঙা অবস্থা ধরা পড়লে চুপ করে ভুল মান ফেরত দেওয়ার বদলে সাথে সাথে থামুন:

function withdraw(account, amount) {
  if (!Number.isSafeInteger(amount) || amount <= 0) {
    throw new RangeError(`টাকার পরিমাণ ঠিক নয়: ${amount}`);
  }
  account.balance -= amount;        // এখানে পৌঁছানো মানে amount বৈধ
  return account.balance;
}

শুরুর এই শর্তটি একটি guard clause (পর্ব ১১) — অবৈধ অবস্থা দরজাতেই আটকানো, যাতে মূল কাজ নিশ্চিন্তে লেখা যায়। throw-এর পরে function-এর আর কোনো লাইন চলে না, return-ও না।

যেকোনো মান ছোড়া যায় — কিন্তু ছুড়বেন শুধু Error

JavaScript খুব উদার: throw "ব্যালান্স কম", throw 404, throw { code: 42 } — সবই বৈধ। কিন্তু string ছুড়লে ধরার জায়গায় পাবেন শুধু একটি string: err.message হবে undefined, err.stack হবে undefined — কোথায় ভুল হলো তার কোনো চিহ্ন নেই। instanceof দিয়ে ধরন বাছাই করা যায় না, error monitoring টুল ঠিকমতো দেখাতে পারে না। Error object তৈরির মুহূর্তেই stack রেকর্ড হয় — এটাই তার আসল মূল্য। তাই নিয়ম: সবসময় throw new Error(...) বা তার কোনো সন্তান। ESLint-এর no-throw-literal নিয়ম ঠিক এটাই পরীক্ষা করে।

Stack unwinding — ধাপে ধাপে

পর্ব ০৫-এ দেখেছেন, প্রতিটি function ডাকলে call stack-এ একটি frame বসে। throw হলে engine সেই স্তূপ উল্টো দিকে খুলতে থাকে — একে বলে stack unwinding. প্রতিটি frame-এ সে খোঁজে: “এখানে কি কোনো try আছে যার ভেতরে এই ডাকটি ঘটেছে?” না থাকলে frame সরিয়ে দেয় — সেই function-এর বাকি লাইন চিরতরে বাদ। নিচের ডায়াগ্রামে a() ডাকে b()-কে, b() ডাকে c()-কে, আর try/catch আছে শুধু a()-তে:

1function c(amount) {2  if (amount > 500) throw new RangeError("সীমা ৫০০ টাকা");3  return amount;4}5function b(amount) {6  const sent = c(amount);7  console.log("b: পাঠানো হলো", sent);8}9function a() {10  try {11    b(900);12    console.log("a: সব ঠিক");13  } catch (err) {14    console.log("a ধরল:", err.message);15  }16  console.log("a: পরের কাজ");17}18a();

৪ · try, catch, finally — ধরা, সামলানো, পরিষ্কার করা

পুরো কাঠামোর তিনটি অংশ। try { … } — যে কোড ব্যর্থ হতে পারে। catch (err) { … } — ব্যর্থ হলে কী করবেন; err-এ আসে ছোড়া মানটি। finally { … } — সফল হোক বা ব্যর্থ, শেষে যা করতেই হবে: লোডিং চিহ্ন সরানো, বাটন আবার চালু করা, ফাইল বা ডেটাবেস সংযোগ বন্ধ করা। try-এর সাথে catch বা finally — অন্তত একটি লাগবে; দুটোও একসাথে চলে। নিচের পাঁচটি অবস্থায় কোন block কখন চলে, খেয়াল করুন:

try {
  console.log("১. টাকা কাটা হলো");
  console.log("২. রসিদ তৈরি");
} catch (err) {
  console.log("সমস্যা:", err.message);   // চলল না
} finally {
  console.log("৩. সংযোগ বন্ধ");
}
→ ১. টাকা কাটা হলো · ২. রসিদ তৈরি · ৩. সংযোগ বন্ধ

try {
  console.log("১. টাকা কাটা হলো");
  throw new Error("প্রিন্টারে কাগজ নেই");
  console.log("২. রসিদ তৈরি");           // বাদ
} catch (err) {
  console.log("সমস্যা:", err.message);
} finally {
  console.log("৩. সংযোগ বন্ধ");
}
→ ১. টাকা কাটা হলো · সমস্যা: প্রিন্টারে কাগজ নেই · ৩. সংযোগ বন্ধ

function save() {
  try {
    throw new Error("ডিস্ক ভর্তি");
  } finally {
    console.log("লোডিং চিহ্ন সরানো");
  }
  console.log("সেভ শেষ");                 // বাদ
}
save();   // → লোডিং চিহ্ন সরানো, তারপর
          //   Uncaught Error: ডিস্ক ভর্তি (কেউ না ধরলে)

function getStatus() {
  try {
    return "সফল";          // ফেরত মান ঠিক হলো, কিন্তু এখনই ফেরা নয়
  } finally {
    console.log("finally চলল");
  }
}
console.log(getStatus());
→ finally চলল
→ সফল

function a() { try { return "try"; } finally { return "finally"; } }
function b() { try { throw new Error("জরুরি"); } finally { return "চুপ"; } }

console.log(a());   // → finally   (try-এর ফল হারাল)
console.log(b());   // → চুপ       (error-টাই উধাও!)

Optional catch binding আর rethrow

কখনো error-এর বিস্তারিত লাগে না — শুধু জানলেই হয় যে ব্যর্থ হয়েছে। ES2019 থেকে তখন (err) বাদ দেওয়া যায় — একে বলে optional catch binding:

function isValidJson(text) {
  try {
    JSON.parse(text);
    return true;
  } catch {                 // err লাগছে না, তাই নাম দেওয়ারও দরকার নেই
    return false;
  }
}

কিন্তু সাবধান: এটি যত সহজ, তত সহজে অপব্যবহার হয়। উপরের function-টি ঠিক আছে, কারণ এখানে “ব্যর্থ” হওয়াই প্রত্যাশিত উত্তর। একটি বড় কাজের চারপাশে try { … } catch {} বসানো মানে কিন্তু সব বাগ লুকিয়ে ফেলা।

catch-এর সোনালি নিয়ম: যা চেনেন আর সামলাতে পারেন, শুধু সেটাই ধরুন; বাকিটা আবার ছুড়ে দিন। JavaScript-এ Java বা Python-এর মতো catch (TypeError e) লেখা যায় না — catch সব ধরে। তাই ভেতরে বাছাই করতে হয়, আর অচেনা হলে rethrow:

try {
  const settings = JSON.parse(savedText);
  applyTheme(settings.theme);       // এখানে বাগ থাকলে TypeError
} catch (err) {
  if (err instanceof SyntaxError) {
    applyTheme("light");            // ভাঙা সেটিংস — ডিফল্টে ফিরুন, এটা প্রত্যাশিত
  } else {
    throw err;                      // অন্য কিছু (বাগ) — চেপে রাখবেন না
  }
}

throw err একই object আবার ছোড়ে, তাই আসল stack অক্ষত থাকে — নতুন Error বানিয়ে শুধু বার্তা কপি করলে সেটা হারাত। আর try block যত ছোট রাখবেন, “কোন লাইনের error ধরছি” তত পরিষ্কার থাকবে।

৫ · নিজের error class আর cause — প্রসঙ্গ যোগ করা

Built-in টাইপগুলো engine-এর ভাষায় কথা বলে: “TypeError”, “SyntaxError”. কিন্তু আপনার অ্যাপের ব্যর্থতা ব্যবসার ভাষায়: “ফোন নম্বর ভুল”, “ব্যালান্স কম”, “অর্ডার লোড হয়নি”. এদের জন্য নিজের error class বানান — পর্ব ২৬-এর extends দিয়ে (inheritance):

class InsufficientFundsError extends Error {
  constructor(balance, amount) {
    super(`ব্যালান্স ${balance} টাকা, চাওয়া হয়েছে ${amount} টাকা`);
    this.name = "InsufficientFundsError";
    this.balance = balance;          // ধরার জায়গায় কাজে লাগবে
    this.shortBy = amount - balance;
  }
}

function withdraw(account, amount) {
  if (amount > account.balance) throw new InsufficientFundsError(account.balance, amount);
  account.balance -= amount;
}

তিনটি জিনিস লক্ষ করুন। super(message) Error-এর নিজের constructor চালায় — message বসে, stack রেকর্ড হয়। this.name না দিলে name থাকত উত্তরাধিকারে পাওয়া "Error", আর stack-এর প্রথম লাইনেও তাই দেখাত। আর বাড়তি field (balance, shortBy) ধরার জায়গাকে বার্তা পার্স না করেই সিদ্ধান্ত নিতে দেয়: “আরও ৪০০ টাকা যোগ করুন” দেখানো সহজ হয়। এখন err instanceof InsufficientFundsError আর err instanceof Error — দুটোই true.

Error cause — নিচের error হারিয়ে না ফেলে ওপরে প্রসঙ্গ যোগ

একটি চেনা সমস্যা: অর্ডার লোড করতে গিয়ে সার্ভারের উত্তর JSON হিসেবে পড়া হলো, আর এলো SyntaxError: Unexpected token '<'…. Log-এ শুধু এটুকু থাকলে কেউ বুঝবে না কোন অর্ডার, কোন কাজ। আবার যদি catch করে নতুন new Error("অর্ডার লোড হয়নি") ছোড়েন, তাহলে আসল কারণ (সার্ভার HTML পাঠিয়েছে) হারিয়ে যায়। ES2022 এর সমাধান দিয়েছে — error cause: দ্বিতীয় argument-এ { cause: err } দিলে নতুন error-এর cause property-তে আসলটি জুড়ে থাকে। ধাপে ধাপে দেখুন:

1class OrderLoadError extends Error { name = "OrderLoadError"; }2function readOrder(text) {3  try {4    return JSON.parse(text);5  } catch (err) {6    throw new OrderLoadError("অর্ডার A-17 লোড হয়নি", { cause: err });7  }8}9try {10  readOrder("<html>502</html>");11} catch (e) {12  console.log(e.name + ": " + e.message);13  console.log("কারণ: " + e.cause.name + ": " + e.cause.message);14}

এবার পুরো ছবিটা একসাথে চালিয়ে দেখুন — একটি অর্ডার ফর্মের যাচাই (ValidationError, কোন ঘরে ভুল সেটা field-এ), cause দিয়ে মোড়া JSON-এর ভুল, আর instanceof দিয়ে বাছাই করে সামলানো:

class ValidationError extends Error {
  name = "ValidationError";
  constructor(field, message) { super(message); this.field = field; }
}
class OrderLoadError extends Error { name = "OrderLoadError"; }
function validateOrder(o) {
  if (o.phone?.length !== 11) throw new ValidationError("phone", "ফোন নম্বর ১১ অঙ্কের হতে হবে");
  if (!(o.qty >= 1)) throw new ValidationError("qty", "পরিমাণ অন্তত ১টি");
}
function loadOrder(text) {
  try { return JSON.parse(text); }
  catch (err) { throw new OrderLoadError("অর্ডার পড়া যায়নি", { cause: err }); }
}
function handle(job) {
  try { job(); console.log("ঠিক আছে"); }
  catch (err) {
    if (err instanceof ValidationError) console.log(err.name, err.field, "→", err.message);
    else if (err instanceof OrderLoadError) console.log(err.name, "→", err.message, "| কারণ:", err.cause.name);
    else throw err;                       // অচেনা — যে বোঝে, তার কাছে যাক
  }
}
handle(() => validateOrder({ phone: "0171", qty: 2 }));
handle(() => validateOrder({ phone: "01711223344" }));
handle(() => loadOrder('{"qty": 2,}'));

৬ · exception নাকি result object? যাচাই, guard clause আর retry

এখন একটি নকশার প্রশ্ন। ব্যালান্স কম হলে withdraw কি exception ছুড়বে, নাকি { ok: false, error } ফেরত দেবে? দুটোই বৈধ — প্রশ্ন হলো ব্যর্থতাটা কতটা “স্বাভাবিক”।

অনেক কোডবেসে আরেকটি মাঝামাঝি পথ চলে: function-এর ভেতরে guard clause দিয়ে throw, আর একেবারে সীমানায় (বাটনের click handler, API route) একটি try/catch, যা error-কে ব্যবহারকারীর বার্তায় রূপান্তর করে। Go আর Rust-এর মতো ভাষা পুরো ভাষাটাই result-ধাঁচে বানিয়েছে (ভাবনার প্রশ্ন ২)। JavaScript-এ দুটোই আছে — মিশিয়ে নয়, একটি স্তরে একটি নিয়ম রাখুন।

Retry — কখন আবার চেষ্টা করা যুক্তিসংগত

Operational error-এর একটি বড় অংশ সাময়িক: নেটওয়ার্ক এক মুহূর্তের জন্য গেল, সার্ভার ব্যস্ত। এখানে সামলানো মানে আবার চেষ্টা। নিচে একটি synchronous অনুকরণ — আসল async retry, অপেক্ষার সময় বাড়ানো (backoff) আর বাতিল করা পর্ব ৩৬-এ:

function makeFlaky(failTimes) {          // প্রথম কয়েকবার "নেটওয়ার্ক" ব্যর্থ হয়
  let calls = 0;
  return () => {
    calls++;
    if (calls <= failTimes) throw new Error(`সংযোগ বিচ্ছিন্ন (চেষ্টা ${calls})`);
    return "SMS পাঠানো হয়েছে";
  };
}
function retry(fn, times) {
  let lastErr;
  for (let i = 1; i <= times; i++) {
    try { return fn(); }
    catch (err) { lastErr = err; console.log("ব্যর্থ:", err.message); }
  }
  throw new Error(`${times} বার চেষ্টাতেও হয়নি`, { cause: lastErr });
}
console.log(retry(makeFlaky(2), 3));
try { retry(makeFlaky(5), 2); }
catch (err) { console.log(err.message, "| শেষ কারণ:", err.cause.message); }

const withdraw = (balance, amount) => amount > balance
  ? { ok: false, error: `ব্যালান্স কম: আছে ${balance} টাকা` }
  : { ok: true, balance: balance - amount };
console.log(withdraw(500, 200), withdraw(500, 900));

৭ · যে error try/catch ধরতে পারে না — callback, timer, promise আর global handler

try/catch শুধু সেই error ধরে, যা try block চলার সময়, একই call stack-এ ছোড়া হয়। একটি পরিচিত ফাঁদ দেখুন:

try {
  setTimeout(() => {
    throw new Error("টাইমারের ভেতরে ভুল");
  }, 1000);
  console.log("টাইমার বসানো হলো");
} catch (err) {
  console.log("ধরা পড়ল?", err.message);   // কখনো চলবে না
}
// প্রত্যাশিত আউটপুট: টাইমার বসানো হলো
// এক সেকেন্ড পরে console-এ: Uncaught Error: টাইমারের ভেতরে ভুল

কেন? setTimeout শুধু callback-টি জমা দেয় আর সাথে সাথে ফিরে আসে। try block শেষ, catch-এর পাহারাও শেষ, stack খালি। এক সেকেন্ড পরে event loop (পর্ব ৩১) callback-টি একটি নতুন, খালি call stack-এ চালায় — সেখানে কোনো try নেই, তাই error uncaught. পর্ব ৩২-এর সব callback, event listener আর timer-এর জন্য নিয়ম একটাই: try/catch লাগবে callback-এর ভেতরে, বাইরে নয়।

Promise আর async/await — এক ঝলক

Asynchronous কাজের ভুল আসে ব্যর্থ (rejected) promise হয়ে। async function-এর ভেতরে await করা promise ব্যর্থ হলে সেটি আবার সাধারণ throw-এর মতো আচরণ করে — চেনা try/catch দিয়েই ধরা যায়। কিন্তু কোনো promise-এর ব্যর্থতা কেউ না সামলালে হয় unhandled rejection: ব্রাউজারে console-এ Uncaught (in promise) আর window-এ unhandledrejection event, Node.js 15 থেকে ডিফল্টে পুরো process বন্ধ। Promise, .catch(), Promise.allSettled আর AggregateError-এর বিস্তারিত পর্ব ৩৩–৩৪-এ।

শেষ জাল — global error handler

সব সাবধানতার পরেও কোনো error ফাঁক গলে বেরোবে। তার জন্য একেবারে ওপরে একটি global error handler রাখা হয় — কাজ রিপোর্ট করা, সামলানো নয়:

// ব্রাউজার: কেউ ধরেনি এমন error আর promise-ব্যর্থতা
window.addEventListener("error", (event) => {
  reportToServer({ message: event.message, stack: event.error?.stack });
});
window.addEventListener("unhandledrejection", (event) => {
  reportToServer({ message: String(event.reason) });
});

// Node.js: log করে বন্ধ হন — চালিয়ে যাবেন না
process.on("uncaughtException", (err) => {
  console.error("অপ্রত্যাশিত ভুল:", err);
  process.exit(1);                    // pm2/systemd/Docker নতুন করে চালু করবে
});

Node.js-এর নিয়মটি গুরুত্বপূর্ণ। uncaughtException-এ পৌঁছানো মানে প্রোগ্রাম এমন অবস্থায় আছে যা কেউ পরিকল্পনা করেনি — হয়তো অর্ধেক লেখা ডেটা, খোলা থাকা সংযোগ। Node.js-এর নিজের documentation-ও বলে: এখানে শুধু সাথে সাথে করা যায় এমন পরিষ্কার আর log, তারপর বন্ধ হওয়া; “কিছুই হয়নি” ভেবে চালিয়ে গেলে পরের ভুলগুলো আরও অদ্ভুত হয়। পুরোনো ধাঁচে লেখা window.onerror = (message, source, line, col, error) => …-ও একই কাজ করে। আর অন্য ডোমেইন থেকে আনা script-এর error ব্রাউজার নিরাপত্তার কারণে শুধু "Script error." হিসেবে দেখায় — বিস্তারিত পেতে সেই script-এ CORS লাগে (পর্ব ৪৩)।

৮ · ব্যবহারকারীর বার্তা, log আর debugging

একই error-এর দুজন পাঠক — ব্যবহারকারী আর ডেভেলপার। দুজনের দরকার সম্পূর্ণ আলাদা।

ব্যবহারকারীর পর্দায় stack trace দেখানো দুইভাবে ক্ষতিকর। সাধারণ মানুষের কাছে এটি ভয়ের আর অর্থহীন। আর আক্রমণকারীর কাছে এটি মানচিত্র — কোন framework, কোন সংস্করণ, কোন ফোল্ডারে কী আছে। একই কারণে log-এ গোপন তথ্য লিখবেন না: log ফাইল প্রায়ই অনেকে দেখেন, তৃতীয় পক্ষের সার্ভিসে যায়, বছরের পর বছর থাকে। Error-এর বার্তায় ব্যবহারকারীর দেওয়া ইনপুট বসালে সেটি পাতায় দেখানোর সময় innerHTML নয়, textContent ব্যবহার করুন (পর্ব ৩৭, ৪৩)।

console.assert — নিজের অনুমান যাচাই

কোডের কোথাও যদি ভাবেন “এখানে মোট দাম কখনো ঋণাত্মক হবে না”, সেই অনুমানটি লিখে রাখুন: console.assert(total >= 0, "মোট দাম ঋণাত্মক!", total). শর্ত মিথ্যা হলে console-এ Assertion failed: মোট দাম ঋণাত্মক! -50 দেখাবে। মনে রাখবেন, console.assert ব্রাউজার বা Node.js-এ exception ছোড়ে না, প্রোগ্রামও থামায় না — এটি উন্নয়নের সময়ের সতর্কসংকেত। সত্যিকারের নিয়ম রক্ষা করতে if (…) throw … লিখুন; এটাই fail fast নীতি — ভুল অবস্থা যত কাছে ধরা পড়ে, খুঁজে পাওয়া তত সহজ (ভাবনার প্রশ্ন ৫)।

Debugging — stack trace থেকে কারণে

• Stack trace পড়ুন নিচ থেকে নিজের কোড খুঁজে: console-এ error-এর পাশের ফাইল-লাইন লিংকে ক্লিক করলে DevTools ঠিক সেই লাইনে নিয়ে যায়। cause থাকলে শিকলের শেষ মাথা পর্যন্ত যান — আসল কারণ প্রায়ই সেখানে।
• Pause on exceptions: DevTools-এর Sources প্যানেলের Breakpoints অংশে “Pause on uncaught exceptions” চালু করলে error ছোড়ার ঠিক মুহূর্তে debugger থামে — তখন সব variable-এর মান আর পুরো call stack চোখের সামনে। “Pause on caught exceptions” চালু করলে catch করা error-এও থামে — কোনো catch কিছু চাপা দিচ্ছে কি না ধরার সেরা উপায়।
• Production-এ error monitoring: ব্যবহারকারীর ব্রাউজারে কী ঘটছে, আপনি দেখতে পান না। Sentry-র মতো সার্ভিস global handler-এর মতো error সংগ্রহ করে, একই ধরনের error একসাথে গুনে দেখায় আর source map দিয়ে minify করা কোডকে মূল লাইনে ফিরিয়ে আনে। ব্যবহারকারীর গোপন তথ্য যেন সেখানে না যায়, সেই সেটিংসও দেখে নিন।

৯ · AI-এর যুগে — error সামলানোর কোডে AI-এর চেনা ভুল

AI-কে কোনো function লিখতে বললে সে প্রায়ই চারপাশে একটি try/catch বসিয়ে দেয় — দেখতে “নিরাপদ” লাগে। কিন্তু error handling-এ ভুল কোড চালালে কিছুই ভাঙে না; ভাঙে পরে, production-এ, যখন একটি চাপা পড়া error তিন দিন ধরে নীরবে ভুল ডেটা লিখে যায়। তাই AI-এর লেখা catch block-গুলো আলাদা করে পড়ুন।

AI-এর লেখা error-কোড — যাচাইয়ের চেকলিস্ট

• কোনো খালি catch {} নেই; প্রতিটি catch হয় সত্যিই সামলায়, নয়তো (প্রসঙ্গসহ) আবার ছোড়ে
• catch block “সব কিছু” ধরে চুপ করে null/false ফেরত দিচ্ছে না; অচেনা error rethrow হচ্ছে
• সব throw-এ Error বা তার subclass; মোড়ানোর সময় { cause: err } আছে
• finally-তে return/throw নেই; try block যতটা সম্ভব ছোট
• callback, timer আর promise-এর error তাদের নিজের জায়গায় ধরা হয়েছে (try-এর বাইরে চলে যাওয়া কোড নেই)
• ব্যবহারকারী কখনো stack trace বা ভেতরের বার্তা দেখেন না; log-এ পাসওয়ার্ড, OTP, token নেই
• নিজে অন্তত তিনটি ব্যর্থতা ঘটিয়ে দেখেছি (ভুল ইনপুট, ভাঙা উত্তর, ইচ্ছাকৃত বাগ), আর DevTools-এ “Pause on caught exceptions” দিয়ে দেখেছি কোথাও কিছু চাপা পড়ছে কি না