exception — checked, unchecked আর try-with-resources

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

একটি মোবাইল ওয়ালেট অ্যাপ ভাবুন। ব্যবহারকারী ৮০০ টাকা পাঠাতে চাইলেন, কিন্তু ব্যালেন্স আছে ৫০০. টাকা তোলার method withdraw() এখন কী করবে? চুপচাপ ব্যালেন্স ঋণাত্মক করে দেবে? সেটা সবচেয়ে খারাপ। শূন্য বা -1 ফেরত দেবে? তাহলে যে method তাকে ডেকেছে, তাকে প্রতিবার মনে করে ফেরত-মান যাচাই করতে হবে — আর একবার ভুলে গেলেই ভুল নীরবে ছড়িয়ে পড়বে। C ভাষায় ঠিক এভাবেই কাজ হয়, আর C-এর অনেক বড় bug এই “ফেরত-মান যাচাই করতে ভুলে যাওয়া” থেকেই আসে।

Java অন্য পথ নেয়। withdraw() নিজে জানে না এই অবস্থায় কী করা উচিত — ব্যবহারকারীকে বার্তা দেখানো, অন্য অ্যাকাউন্ট থেকে নেওয়া, নাকি লেনদেন বাতিল — সেটা ঠিক করবে ওপরের কোনো কোড। তাই সে একটি exception ছুড়ে দেয়: একটি object, যার ভেতরে লেখা থাকে কী ভুল হলো (টাইপ আর বার্তা) আর কোথায় হলো (stack trace). ছোড়ামাত্র method-এর বাকি কোড আর চলে না।

exception ছোড়া হলে JVM একটি নির্দিষ্ট কাজ করে: যে method-এ exception ঘটেছে, সেখানে মিলে যাওয়া catch আছে কি না দেখে। না থাকলে সেই method-এর frame call stack থেকে সরিয়ে দেয় আর তাকে যে ডেকেছিল তার কাছে যায়। এভাবে একটির পর একটি frame সরানোকে বলে stack unwinding. কেউ না ধরলে main-ও সরে যায়, প্রোগ্রাম থেমে যায়, আর standard error-এ ছাপা হয় একটি stack trace. তিনটি method-এর একটি ছোট শিকলে ব্যাপারটা দেখুন:

1void withdraw(long amt) throws InsufficientBalanceException {2    if (amt > balance)3        throw new InsufficientBalanceException(...);4    balance -= amt;5}6void transfer(Wallet w, long amt) throws InsufficientBalanceException {7    w.withdraw(amt);8    System.out.println("পাঠানো হলো");9}10public static void main(String[] args) {11    try {12        transfer(wallet, 800);13    } catch (InsufficientBalanceException e) {14        System.out.println("ব্যর্থ: " + e.getMessage());15    }16    System.out.println("অ্যাপ চলছে");17}

২ · পরিবারের গাছ — Throwable, Error, Exception, RuntimeException

Java-তে যেকোনো object ছোড়া যায় না। ছোড়া যায় শুধু Throwable class-এর বংশধরদের। এই গাছটি পুরো পর্বের মানচিত্র, তাই একবার ভালো করে দেখে নিন:

Throwable
├── Error                         ← unchecked · JVM-এর গুরুতর সমস্যা
│   ├── OutOfMemoryError
│   └── StackOverflowError
└── Exception                     ← checked (RuntimeException বাদে)
    ├── IOException
    │   └── FileNotFoundException
    ├── InsufficientBalanceException   (নিজের বানানো, checked)
    └── RuntimeException          ← unchecked · সাধারণত প্রোগ্রামের ভুল
        ├── NullPointerException
        ├── ArithmeticException
        ├── IllegalArgumentException
        │   └── NumberFormatException
        ├── IllegalStateException
        ├── IndexOutOfBoundsException
        │   └── ArrayIndexOutOfBoundsException
        └── ClassCastException

Error শাখার নামগুলো ...Error দিয়ে শেষ হয়, আর Exception শাখারগুলো ...Exception দিয়ে — এই নামকরণই অর্ধেক কাজ করে দেয়। মনে রাখার সহজ নিয়ম: RuntimeException বা Error-এর নিচে হলে unchecked, Exception-এর নিচে বাকি সব checked. এই ভাগ শুধু compiler-এর নিয়ম; চলার সময় দুই ধরনের exception হুবহু একইভাবে ছোড়া, ধরা আর unwind হয়।

৩ · stack trace পড়া — ওপর থেকে নিচে, “Caused by” পর্যন্ত

নতুনরা stack trace দেখলে ভয় পান — লাল লাল লেখা, অনেক লাইন। কিন্তু এটি আসলে একটি সুন্দর গোয়েন্দা-রিপোর্ট। নিচের প্রোগ্রামে withdraw একটি checked exception ছোড়ে, transfer সেটা ধরে আরেকটি exception-এ মুড়ে আবার ছোড়ে (এটাকে বলে chaining, অংশ ৭-এ বিস্তারিত), আর কেউ শেষটা ধরে না:

class InsufficientBalanceException extends Exception {
    InsufficientBalanceException(String msg) { super(msg); }
}
class Wallet {
    private long balance;
    Wallet(long balance) { this.balance = balance; }
    void withdraw(long amount) throws InsufficientBalanceException {
        if (amount > balance)
            throw new InsufficientBalanceException("balance " + balance + ", requested " + amount);
        balance -= amount;
    }
}
class Main {
    static void transfer(Wallet from, long amount) {
        try {
            from.withdraw(amount);
        } catch (InsufficientBalanceException e) {
            throw new IllegalStateException("transfer failed", e);
        }
    }
    public static void main(String[] args) {
        transfer(new Wallet(500), 800);
    }
}

Exception in thread "main" java.lang.IllegalStateException: transfer failed
	at Main.transfer(Main.java:18)
	at Main.main(Main.java:22)
Caused by: InsufficientBalanceException: balance 500, requested 800
	at Wallet.withdraw(Main.java:9)
	at Main.transfer(Main.java:16)
	... 1 more

এভাবে পড়ুন:

• প্রথম লাইন — কী আর কোন thread-এ: main thread-এ একটি java.lang.IllegalStateException, বার্তা transfer failed. নিজের বানানো class-এর আগে package নেই, তাই InsufficientBalanceException শুধু নামেই দেখায়।
• at লাইনগুলো — সবচেয়ে ওপরেরটি যেখানে exception তৈরি হয়েছে: Main.transfer, ১৮ নম্বর লাইন। তার নিচে যে তাকে ডেকেছে — main, ২২ নম্বর লাইন। অর্থাৎ ওপরের লাইন = সবচেয়ে নতুন frame, ঠিক stack-এর মতো।
• Caused by: — আসল কারণ: ভেতরে মোড়ানো exception. এখানেই আসল গল্প: Wallet.withdraw-এর ৯ নম্বর লাইনে ব্যালেন্স কম পাওয়া গেছে। লম্বা trace-এ সবচেয়ে নিচের Caused by খুঁজুন — মূল কারণ সাধারণত সেখানে।
• ... 1 more: বাকি frame-গুলো ওপরের trace-এর সাথে হুবহু মিলে যায় (এখানে main), তাই আবার না ছেপে সংক্ষেপ করা হয়েছে।

আসল প্রজেক্টে trace-এ থাকবে কয়েক ডজন লাইন — Spring, Tomcat বা JDK-র ভেতরের method. কৌশল একটাই: নিজের package-এর প্রথম লাইনটি খুঁজুন। লাইব্রেরির ভেতরে bug থাকার সম্ভাবনা কম; সাধারণত ভুল argument গেছে আপনার কোড থেকেই।

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

exception ধরতে হলে যে কোডে সেটি আসতে পারে তা try block-এ রাখুন, আর ঠিক পরে এক বা একাধিক catch লিখুন — একে বলে try-catch. প্রতিটি catch একটি টাইপ ধরে: সেই class বা তার যেকোনো subclass. শেষে ঐচ্ছিক finally block, যা সবসময় চলে।

try {
    int amount = Integer.parseInt(input);       // NumberFormatException আসতে পারে
    wallet.withdraw(amount);                    // InsufficientBalanceException আসতে পারে
} catch (NumberFormatException e) {
    System.out.println("সংখ্যা লিখুন");
} catch (InsufficientBalanceException e) {
    System.out.println("ব্যালেন্স কম: " + e.getMessage());
} finally {
    System.out.println("লেনদেনের চেষ্টা শেষ");     // সবসময় চলে
}

catch-এর ক্রম — ছোট (subclass) আগে, বড় পরে

exception এলে Java catch-গুলো ওপর থেকে নিচে পরীক্ষা করে, আর প্রথম যেটি মেলে সেটিই চলে — বাকিগুলো দেখে না। তাই বড় টাইপ (যেমন Exception) আগে রাখলে পরের ছোট টাইপের catch কখনো পৌঁছানোই যাবে না। Java এমন মরা কোড মেনে নেয় না:

try {
    int n = Integer.parseInt(args[0]);
    System.out.println(n);
} catch (Exception e) {
    System.out.println("something went wrong");
} catch (NumberFormatException e) {              // ✗ এখানে আর কখনো আসবে না
    System.out.println("not a number");
}

Main.java:8: error: exception NumberFormatException has already been caught
        } catch (NumberFormatException e) {
          ^
1 error

সমাধান: ক্রম উল্টে দিন — NumberFormatException আগে, Exception পরে। নিয়মটা গাছ থেকেই আসে: NumberFormatException হলো IllegalArgumentException-এর subclass, সেটি আবার RuntimeException-এর, সেটি Exception-এর।

multi-catch — একই সামলানো, কয়েকটি টাইপ

দুটি সম্পর্কহীন exception-এর জন্য একই কাজ করতে চাইলে Java 7 থেকে multi-catch আছে: catch (IllegalArgumentException | InsufficientBalanceException e). শর্ত একটাই — টাইপগুলো একে অপরের subclass হতে পারবে না, কারণ তাহলে ছোটটি লেখা অর্থহীন:

Main.java:5: error: Alternatives in a multi-catch statement cannot be related by subclassing
        } catch (NumberFormatException | IllegalArgumentException e) {
                                         ^
  Alternative NumberFormatException is a subclass of alternative IllegalArgumentException
1 error

finally — সবসময় চলে, এমনকি return-এর পরেও

finally-র প্রতিশ্রুতি হলো: try থেকে স্বাভাবিকভাবে বেরোন, exception নিয়ে বেরোন, অথবা return দিয়ে বেরোন — finally চলবেই (ব্যতিক্রম শুধু System.exit() বা JVM নিজেই বন্ধ হয়ে গেলে)। নিচের method-টি দুইবার ডাকা হয়: একবার ঠিক ইনপুটে, একবার ভুল ইনপুটে। শেষ ধাপে একটি ফাঁদও আছে:

1static int pay(String input) {2    try {3        int amt = Integer.parseInt(input);4        System.out.println("try: " + amt);5        return amt;6    } catch (NumberFormatException e) {7        System.out.println("catch: সংখ্যা নয়");8        return -1;9    } finally {10        System.out.println("finally");11    }12}

শেষ ধাপের ফাঁদটি যাচাই করা: try { throw new IllegalStateException("lost!"); } finally { return 2; } লেখা method কোনো exception ছাড়াই 2 ফেরত দেয় — "lost!" চিরতরে উধাও। javac এটা ডিফল্টে আটকায় না; শুধু -Xlint:finally চালু করলে finally clause cannot complete normally সতর্কবার্তা দেয়। এটি swallowed exception-এর সবচেয়ে লুকোনো রূপ।

৫ · throw আর throws — ছোড়া আর আগাম ঘোষণা

দুটি শব্দ দেখতে প্রায় এক, কাজ সম্পূর্ণ আলাদা:

throw দিয়ে আপনি নিজে ব্যর্থতা ঘোষণা করেন। throws দিয়ে method তার চুক্তিতে লিখে রাখে কোন checked exception সে বাইরে পাঠাতে পারে — যেমন পর্ব ১২-এ শিখেছেন method-এর signature বলে সে কী নেয় আর কী ফেরত দেয়, তেমনি throws বলে সে কীভাবে ব্যর্থ হতে পারে।

compiler-এর পাহারা

checked exception ছোড়ে এমন method ডেকে যদি আপনি ধরেনও না, ঘোষণাও না করেন, compiler থামিয়ে দেয়। নিচের ফাইলের ১৪ নম্বর লাইনে main সরাসরি w.withdraw(800) ডেকেছে, কোনো try ছাড়া:

Main.java:14: error: unreported exception InsufficientBalanceException; must be caught or declared to be thrown
        w.withdraw(800);
                  ^
1 error

বার্তাটি নিজেই দুটি পথ বলে দিচ্ছে: caught — try/catch দিয়ে এখানেই সামলান; অথবা declared to be thrown — নিজের ঘোষণায় throws InsufficientBalanceException লিখে দায়িত্ব ওপরে পাঠান। কোনটা ঠিক, তা নির্ভর করে এই method সমস্যাটি সামলানোর মতো তথ্য রাখে কি না। ওয়ালেটের নিচের স্তরের কোড জানে না ব্যবহারকারীকে কী দেখাতে হবে, তাই ঘোষণা করে; UI-এর কাছাকাছি কোড ধরে।

উল্টো দিকেও compiler সতর্ক। যে checked exception try-এর ভেতরে কখনো আসতেই পারে না, তার জন্য catch লিখলে সেটাও error: exception InsufficientBalanceException is never thrown in body of corresponding try statement. unchecked-এর ক্ষেত্রে দুই দিকেই compiler চুপ — আপনি চাইলে throws IllegalArgumentException লিখতে পারেন নথি হিসেবে, কিন্তু বাধ্যতামূলক নয়।

৬ · unchecked exception আর নিজের exception

প্রতিদিন যে unchecked exception-গুলো দেখবেন, সেগুলো চিনে রাখুন। প্রতিটির বার্তা Java 21-এ চালিয়ে যাচাই করা:

এগুলোর বেশিরভাগ JVM বা JDK নিজে ছোড়ে। ব্যতিক্রম দুটি — IllegalArgumentException আর IllegalStateException — যা আপনি নিজের method-এ সবচেয়ে বেশি ব্যবহার করবেন, fail-fast নীতিতে: ভুল মান ঢোকামাত্র থামুন, গভীরে ঢুকে অদ্ভুত ফল দেওয়ার আগে। null যাচাইয়ের জন্য JDK-তে তৈরি সহজ হাতিয়ার আছে, Objects.requireNonNull:

Wallet(String owner, long balance) {
    this.owner = Objects.requireNonNull(owner, "owner must not be null");
    if (balance < 0) throw new IllegalArgumentException("balance < 0: " + balance);
    this.balance = balance;
}

null এলে সাথে সাথে java.lang.NullPointerException: owner must not be null — কোন জিনিস null ছিল, তা constructor-এর প্রথম লাইনেই স্পষ্ট। না হলে null চুপচাপ field-এ বসে থাকত আর অনেক পরে, সম্পূর্ণ অন্য জায়গায় NPE দিত।

নিজের exception — Exception না RuntimeException থেকে?

JDK-র exception দিয়ে কাজ না চললে নিজে বানান — একটি custom exception সাধারণত একটি ছোট class, যার constructor বার্তাটি super(...)-এ পাঠায়। আসল সিদ্ধান্ত হলো parent কে হবে:

• extends Exception (checked): ঠিকঠাক কোডেও এটি ঘটতে পারে, আর ডাকার কোড বাস্তবে কিছু করতে পারে — ব্যবহারকারীকে বলা, কম টাকা পাঠানোর প্রস্তাব দেওয়া। InsufficientBalanceException এর আদর্শ উদাহরণ: ব্যালেন্স কম হওয়া bug নয়, ব্যবসার স্বাভাবিক একটি ফল।
• extends RuntimeException (unchecked): এটি ঘটা মানে কোথাও প্রোগ্রামের ভুল, অথবা ডাকার কোড কিছুই করতে পারবে না শুধু থেমে যাওয়া ছাড়া। আধুনিক অনেক framework (যেমন Spring) প্রায় সব exception-ই unchecked রাখে।

এবার সব একসাথে — একটি ওয়ালেট, ব্যবহারকারীর লেখা চারটি ইনপুট, আর তিন ধরনের ব্যর্থতা। চালিয়ে দেখুন:

class InsufficientBalanceException extends Exception {
    InsufficientBalanceException(String message) { super(message); }
}
class Wallet {
    private long balance = 500;
    void withdraw(long amount) throws InsufficientBalanceException {
        if (amount <= 0) throw new IllegalArgumentException("পরিমাণ ধনাত্মক নয়: " + amount);
        if (amount > balance) throw new InsufficientBalanceException("ব্যালেন্স " + balance + ", চাওয়া " + amount);
        balance -= amount;
        System.out.println(amount + " টাকা তোলা হলো, বাকি " + balance);
    }
}
class Main {
    public static void main(String[] args) {
        var w = new Wallet();
        for (String input : new String[] {"200", "12a", "800", "-5"})
            try {
                w.withdraw(Long.parseLong(input));
            } catch (NumberFormatException e) {
                System.out.println("সংখ্যা নয়: " + e.getMessage());
            } catch (IllegalArgumentException | InsufficientBalanceException e) {
                System.out.println("বাতিল: " + e.getMessage());
            }
    }
}

নতুন exception বানানোর আগে কোন পথে যাবেন, এই প্রশ্নগুলো ধাপে ধাপে জিজ্ঞেস করুন:

findUser("01711...") → ব্যবহারকারী নেই
এটা স্বাভাবিক ফল, ব্যতিক্রম নয়
→ Optional<User> ফেরত দিন (পর্ব ৩৬)

withdraw(-5), null owner, বন্ধ ওয়ালেট
ডাকার কোড ঠিক করলেই আর ঘটবে না
→ IllegalArgumentException / IllegalStateException

withdraw(800), ব্যালেন্স 500
ব্যবহারকারীকে জানানো, কম টাকার প্রস্তাব
→ InsufficientBalanceException extends Exception

config ফাইল ভাঙা, ডেটাবেসের পাসওয়ার্ড ভুল
প্রতিটি স্তরে throws লিখে কোনো লাভ নেই
→ unchecked (cause সহ), সবচেয়ে ওপরে একবার লগ

IllegalArgumentException, IllegalStateException,
UnsupportedOperationException, IOException...
চেনা নাম = সবাই বোঝে; নিজেরটা শুধু যখন
ডাকার কোডকে আলাদা করে ধরতে হবে

৭ · chaining আর ভালো অভ্যাস — exception নষ্ট করবেন না

অংশ ৩-এর stack trace-এ Caused by এসেছিল এক লাইনের কারণে: throw new IllegalStateException("transfer failed", e);. দ্বিতীয় argument e হলো cause — নতুন exception-এর ভেতরে পুরোনোটি রেখে দেওয়া। একে বলে exception chaining. এর উদ্দেশ্য দুটি: ওপরের স্তরকে তার নিজের ভাষায় একটি exception দেওয়া (“transfer ব্যর্থ”, ভেতরের ডেটাবেস-বিবরণ নয়), আর একই সাথে আসল কারণ না হারানো। e.getCause() দিয়ে ভেতরেরটি পাওয়া যায়। নিজের exception-এও তাই (String message, Throwable cause) constructor রাখুন, যা super(message, cause) ডাকে।

যে অভ্যাসগুলো exception-কে অকেজো করে

try {
    wallet.withdraw(amount);
} catch (InsufficientBalanceException e) {
    // পরে দেখব
}

try {
    processOrder(order);
} catch (Exception e) {
    e.printStackTrace();
}

try {
    wallet.withdraw(amount);
} catch (InsufficientBalanceException e) {
    ui.showError("ব্যালেন্স কম: " + e.getMessage());   // এখানে সামলানো যায়
}

try {
    repository.save(order);
} catch (IOException e) {
    throw new OrderFailedException("order " + id, e);  // নিজের ভাষায়, cause সহ
}

exception শুধু ব্যতিক্রমের জন্য — control flow নয়

কেউ কেউ লুপ থামাতে exception ব্যবহার করেন — array-এর শেষ পর্যন্ত চলতে থাকেন, আর ArrayIndexOutOfBoundsException ধরে লুপ থেকে বেরোন। এটা কাজ করে, কিন্তু তিন কারণে ভুল। প্রথমত, পড়তে বিভ্রান্তিকর — catch দেখলে পাঠক ভাবেন কিছু ভুল হয়েছে। দ্বিতীয়ত, সত্যিকারের bug লুকিয়ে যায়: লুপের ভেতরে অন্য কোনো index ভুল হলে সেটাও “লুপ শেষ” বলে ধরা পড়বে। তৃতীয়ত, ধীর।

ধীর কেন? exception object তৈরির সময় Throwable-এর constructor fillInStackTrace() ডাকে, যা সেই মুহূর্তের পুরো call stack হেঁটে রেকর্ড করে। stack যত গভীর, খরচ তত বেশি — আর তারপর unwinding-এর খরচ। একবারের ব্যর্থতায় এটা নগণ্য; প্রতি সেকেন্ডে লক্ষবার হলে চোখে পড়ার মতো। তাই নিয়ম: যা আগে থেকে যাচাই করা যায় (index সীমার মধ্যে কি না, ইনপুট খালি কি না), তা if দিয়ে যাচাই করুন; exception রাখুন সত্যিকারের অপ্রত্যাশিত ঘটনার জন্য।

৮ · try-with-resources — খোলা জিনিস নিশ্চিতভাবে বন্ধ

ফাইল, ডেটাবেস সংযোগ, নেটওয়ার্ক socket — এগুলো খোলার পর বন্ধ করা বাধ্যতামূলক। না করলে operating system-এর সীমিত file handle বা ডেটাবেসের সংযোগ ফুরিয়ে যায়, আর সার্ভার কয়েক ঘণ্টা পর রহস্যজনকভাবে থেমে যায়। Java 7-এর আগে এটা লিখতে হতো finally দিয়ে, null-যাচাই আর close()-এর নিজের exception-এর জন্য আরেকটি try সহ — দশ লাইনের অনুষ্ঠান, যা প্রায়ই ভুল লেখা হতো।

Java 7 আনল try-with-resources: try-এর পরের বন্ধনীতে সম্পদ খুলুন, block শেষ হলে — স্বাভাবিকভাবে বা exception নিয়ে — Java নিজেই close() ডাকবে। শর্ত একটাই: object-টিকে AutoCloseable implement করতে হবে, যে interface-এ শুধু একটি method: void close() throws Exception. JDK-র প্রায় সব stream, reader, JDBC সংযোগ এটি করে। নিজের class-ও করতে পারে — নিচে একটি নকল “config” আর “log” সম্পদ, যারা খোলা আর বন্ধ হওয়ার সময় ছাপে। log বন্ধ করার সময় নিজেও একটি exception দেয়:

খোলা হলো: config
খোলা হলো: log

config পড়া হচ্ছে...
throw IllegalArgumentException("লাইন 3 ভুল")
→ এখনই catch নয়; আগে resource বন্ধ

বন্ধ হলো: log
log.close() নিজেও ছুড়ল:
IllegalStateException("log বন্ধ করতে সমস্যা")

মূল: IllegalArgumentException("লাইন 3 ভুল")
  └─ suppressed: IllegalStateException("log ...")
তারপর: বন্ধ হলো: config

ধরা হলো: লাইন 3 ভুল
  suppressed: log বন্ধ করতে সমস্যা

finally চলল
ক্রম: খোলা → body → বন্ধ (উল্টো) → catch → finally

record Resource(String name, boolean failOnClose) implements AutoCloseable {
    Resource {
        System.out.println("খোলা হলো: " + name);
    }
    @Override public void close() {
        System.out.println("বন্ধ হলো: " + name);
        if (failOnClose) throw new IllegalStateException(name + " বন্ধ করতে সমস্যা");
    }
}
class Main {
    public static void main(String[] args) {
        try (var config = new Resource("config", false);
             var log = new Resource("log", true)) {
            System.out.println("config পড়া হচ্ছে...");
            throw new IllegalArgumentException("লাইন 3 ভুল");
        } catch (IllegalArgumentException e) {
            System.out.println("ধরা হলো: " + e.getMessage());
            for (Throwable s : e.getSuppressed())
                System.out.println("  suppressed: " + s.getMessage());
        } finally {
            System.out.println("finally চলল");
        }
    }
}

বাস্তবে ফাইল পড়া ঠিক এই কাঠামোতেই হয় — try (var reader = Files.newBufferedReader(path)) { ... } — আর সেখানে IOException checked, তাই catch বা throws লাগবে। java.nio.file দিয়ে আসল ফাইল নিয়ে কাজ পর্ব ৩৭-এ।

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

AI-কে কোনো ফাইল পড়া বা API ডাকার কোড লিখতে বললে প্রায়ই দেখবেন: প্রতিটি method-এর চারপাশে try { ... } catch (Exception e) { e.printStackTrace(); }. কোড compile হয়, demo-তে চলে, আর প্রথম আসল ব্যর্থতায় প্রোগ্রাম ভুল অবস্থায় চলতে থাকে — কোনো লগ ফাইলে কিছু নেই, শুধু কোথাও stderr-এ কয়েকটি লাইন যা কেউ দেখে না। এই অভ্যাস এসেছে ইন্টারনেটের অসংখ্য টিউটোরিয়াল আর উত্তর থেকে, যেখানে উদ্দেশ্য ছিল শুধু compiler-কে চুপ করানো।

AI-এর কোড হাতে পেলে — যাচাইয়ের চেকলিস্ট

• কোনো catch (Exception e) বা catch (Throwable t) নেই (সবচেয়ে ওপরের স্তরের একটি জায়গা ছাড়া)
• কোনো ফাঁকা catch নেই, আর প্রতিটি catch হয় সামলায় নয় cause সহ আবার ছোড়ে
• নতুন exception বানানোর সময় পুরোনোটি cause হিসেবে দেওয়া আছে
• সব stream, reader, connection try-with-resources-এ
• finally-তে কোনো return নেই
• exception দিয়ে লুপ থামানো বা স্বাভাবিক ফল বোঝানো হয়নি
• exception-এর বার্তায় সমস্যা বোঝার মতো তথ্য আছে (মান, id) — কিন্তু পাসওয়ার্ড বা PIN নেই