exception — ভুল সামলানো: try, except আর raise

১ · Exception আসলে কী — “আমি এখানে আর এগোতে পারছি না”

পর্ব ০৪-এ প্রথম লাল লেখার traceback দেখেছিলেন, আর শিখেছিলেন সেটি নিচ থেকে ওপরে পড়তে হয়। তখন এটিকে শুধু “ভুলের বার্তা” হিসেবে দেখেছিলেন। এই পর্বে প্রশ্নটি বদলাবে: ভুল হলে Python ভেতরে আসলে কী করে, আর আপনি কীভাবে সেই ভুল ধরে প্রোগ্রামকে বাঁচিয়ে রাখবেন?

একটি উদাহরণ দিয়ে শুরু করি। বন্ধুরা মিলে রেস্টুরেন্টে খেয়েছেন, বিল ৯০০ টাকা। একটি ফাংশন বিলকে মানুষের সংখ্যা দিয়ে ভাগ করে। কেউ ভুল করে মানুষের সংখ্যা ০ দিল। 900 / 0 — গণিতেই এর কোনো উত্তর নেই। Python তখন কী করবে? চুপচাপ ০ ফেরত দেবে? একটি বানানো সংখ্যা দেবে? দুটোই হতো ভয়ংকর, কারণ ভুল ফল নিয়ে প্রোগ্রাম এগিয়ে যেত আর কেউ টেরও পেত না।

Python তার বদলে একটি exception তোলে — এখানে ZeroDivisionError. Exception হলো একটি object, যার ভেতরে লেখা থাকে কী ধরনের সমস্যা, কী বার্তা, আর কোথায় ঘটেছে। এর মানে মোটামুটি এই: “এই লাইনের কাজ আমি শেষ করতে পারছি না। যে জানে কী করতে হবে, সে সামলাক।”

পর্ব ১৩-এ দেখেছিলেন, ফাংশন যখন আরেকটি ফাংশনকে ডাকে, Python একটি call stack বানায় — প্রতিটি চলমান ডাকের জন্য একটি করে stack frame. Exception ঠিক এই stack ধরে ওপরে ওঠে। প্রথমে দেখে যে ফাংশনে ভুলটি ঘটল, সেখানে কোনো ধরার ব্যবস্থা আছে কি না। না থাকলে সেই ফাংশন সেখানেই শেষ — তার frame মুছে যায় — আর exception চলে যায় তাকে যে ডেকেছিল তার কাছে। একে বলে exception propagation, আর পথে frame-গুলো একে একে সরিয়ে ফেলাকে বলে stack unwinding.

নিচের প্রোগ্রামে তিনটি ফাংশন: main ডাকে checkout-কে, checkout ডাকে pay-কে। ভুল ঘটে সবচেয়ে ভেতরের pay-এ, কিন্তু সামলানো হয় সবচেয়ে বাইরের main-এ। মাঝের checkout ভুলটি ধরে না, কিন্তু পথে তার finally অংশ ঠিকই চলে (finally-এর বিস্তারিত অংশ ৩-এ)। “পরে” চাপুন:

1def pay(balance, amount):2    if amount > balance:3        raise InsufficientBalance("টাকা কম")4    return balance - amount5def checkout(total):6    try:7        return pay(300, total)8    finally:9        print("কার্ট আনলক")10def main():11    try:12        checkout(500)13    except InsufficientBalance as e:14        print("দুঃখিত:", e)15main()

কেউ না ধরলে কী হয়? Exception সবচেয়ে বাইরের module স্তর পর্যন্ত উঠে যায়, Python প্রোগ্রাম থামিয়ে দেয় আর stderr-এ traceback ছাপে। এবার পর্ব ০৪-এর সেই লাইনটির মানে নতুন করে বোঝা যায়: Traceback (most recent call last)-এর নিচের প্রতিটি File ... line ... হলো stack-এর একটি frame, exception যার ভেতর দিয়ে উঠে এসেছে। সবচেয়ে নিচের frame হলো যেখানে ভুলটি জন্মেছিল।

২ · try/except — যে ভুল সামলাতে জানেন, সেটিই ধরুন

Exception ধরার যন্ত্রটি হলো try/except. গঠন খুব সরল: যে কোডে ভুল হতে পারে, সেটি রাখুন try:-এর নিচে; ভুল হলে কী করবেন, সেটি রাখুন except-এর নিচে, সঙ্গে ভুলের ধরনের নাম:

def split_bill(total, people):
    try:
        return total / people
    except ZeroDivisionError:
        print("মানুষের সংখ্যা ০ হতে পারে না")
        return None

split_bill(900, 3) দিলে 300.0 ফেরত আসে, except-এর অংশ ছোঁয়াই হয় না। split_bill(900, 0) দিলে total / people লাইনে ZeroDivisionError ওঠে, Python try-এর বাকি অংশ বাদ দিয়ে সোজা মিলে যাওয়া except-এ লাফ দেয়। ভুল সামলানো হলো, প্রোগ্রাম চলতে থাকল।

কেন নির্দিষ্ট ধরন লিখতে হয়

except-এর পরে ধরনের নাম লেখা ঐচ্ছিক মনে হতে পারে। কিন্তু এটিই সবচেয়ে গুরুত্বপূর্ণ সিদ্ধান্ত। ধরুন split_bill-এ কেউ people হিসেবে "3" (string) পাঠাল। তখন আসবে TypeError, ZeroDivisionError নয়। এই ভুল ধরার কোনো except নেই, তাই সেটি ওপরে চলে যাবে — আর এটাই ঠিক. কারণ “৩ জন মানুষ string হিসেবে এসেছে” মানে কোডের অন্য কোথাও বাগ আছে; এখানে “মানুষের সংখ্যা ০” বলে বার্তা দিলে মিথ্যা বলা হতো।

একাধিক ধরন ধরা

একই কোডে কয়েক রকম ভুল হতে পারে। দুটি উপায় আছে। প্রতিটির জন্য আলাদা আচরণ চাইলে আলাদা except লিখুন; Python ওপর থেকে নিচে মিলিয়ে দেখে, আর প্রথম যেটি মেলে শুধু সেটিই চলে. আর কয়েকটি ধরনের জন্য একই আচরণ চাইলে একটি tuple দিন:

def parse_qty(text, stock):
    try:
        qty = int(text)
        return stock[qty]
    except ValueError:
        print("সংখ্যা লিখুন")
    except (IndexError, KeyError):
        print("এই নম্বরের পণ্য নেই")

int("দুই") দিলে ValueError, তালিকার বাইরের নম্বরে IndexError, dict হলে KeyError. (Python 3.14 থেকে as না থাকলে বন্ধনী ছাড়াও except IndexError, KeyError: লেখা যায়, কিন্তু পুরোনো version-এ সেটি SyntaxError — তাই বন্ধনী দেওয়াই নিরাপদ।)

as e — exception object হাতে নেওয়া

বার্তাটি দেখাতে বা লগ করতে চাইলে except ValueError as e: লিখুন। এখন e হলো সেই exception object. str(e) বা print(e) দেয় বার্তা, type(e).__name__ দেয় ধরনের নাম। একটি সূক্ষ্ম তথ্য: except block শেষ হলেই Python নিজে থেকে e নামটি মুছে দেয়। কারণ exception-এর সাথে তার traceback আর সব frame জোড়া থাকে; নামটি রেখে দিলে সেগুলো মেমরিতে আটকে থাকত। পরে লাগলে block-এর ভেতরেই অন্য নামে রেখে দিন।

except Exception আর খালি except: — বিপজ্জনক জাল

কখনো সত্যিই “যেকোনো ভুল” ধরতে হয় — যেমন একটি ওয়েব সার্ভার, যেটি একজন ব্যবহারকারীর অনুরোধে বাগ পেলেও বাকিদের সেবা বন্ধ করবে না। তখন লেখা হয় except Exception as e:, আর অবশ্যই ভুলটি লগ করা হয়। কিন্তু bare except — অর্থাৎ ধরন ছাড়া খালি except: — আরও অনেক বেশি ধরে। সে ধরে BaseException-এর সব সন্তান, যার মধ্যে আছে:

• KeyboardInterrupt — ব্যবহারকারী Ctrl+C চাপলে এটি ওঠে। খালি except: একে গিলে ফেললে লুপে আটকে থাকা প্রোগ্রাম আর Ctrl+C দিয়ে বন্ধ করা যায় না।
• SystemExit — sys.exit() ডাকলে এটি ওঠে। খালি except: একে ধরলে প্রোগ্রাম বন্ধ হতে চেয়েও পারে না।
• GeneratorExit — generator বন্ধ করার সংকেত (পর্ব ৩৪)।

এজন্য PEP 8 সরাসরি বলে: খালি except: এড়ান; যদি সত্যিই সব ধরতে হয়, অন্তত except Exception: লিখুন। আর তাও কেবল প্রোগ্রামের একেবারে বাইরের স্তরে, ভুলটি লগ করে।

৩ · else আর finally — সফলতার কাজ আর পরিষ্কারের কাজ

try-এর সাথে আরও দুটি অংশ যোগ করা যায়। পুরো গঠন, এই ক্রমেই:

1. try: — যে কাজে ভুল হতে পারে (যত ছোট রাখা যায়, তত ভালো)
2. except ...: — এক বা একাধিক; নির্দিষ্টগুলো আগে, সাধারণগুলো পরে
3. else: — চলে শুধু তখন, যখন try-তে কোনো exception ওঠেনি
4. finally: — চলে সবসময়: সফল হলেও, ধরা ভুলেও, না-ধরা ভুলেও, এমনকি try-এর ভেতরে return থাকলেও

else কেন দরকার, সব কোড try-এর ভেতরে রাখলেই তো হয়? না, কারণ তখন try বড় হয়ে যায়, আর except এমন লাইনের ভুলও ধরে ফেলতে পারে যার জন্য সেটি লেখা হয়নি। else বলে: “ভুল-প্রবণ কাজটি সফল হয়েছে; এবার বাকি কাজ — কিন্তু এর ভুল আমি এখানে ধরব না।” আর finally হলো finally — পরিষ্কারের জায়গা: ফাইল বন্ধ করা, লক ছেড়ে দেওয়া, অস্থায়ী জিনিস মুছে ফেলা।

নিচের stepper-এ একই বিল-ভাগের কোড দুবার চলবে — প্রথমে সফলভাবে (৩ জন), তারপর ভুল নিয়ে (০ জন)। কোন লাইন কখন চলে, খেয়াল করুন:

1try:2    share = total / people3except ZeroDivisionError:4    print("মানুষ ০ জন?")5else:6    print("জনপ্রতি", share)7finally:8    print("হিসাব শেষ")9print("পরের কাজ")

1try:2    share = total / people3except ZeroDivisionError:4    print("মানুষ ০ জন?")5else:6    print("জনপ্রতি", share)7finally:8    print("হিসাব শেষ")9print("পরের কাজ")

এবার এই পর্বের প্রথম চালানো যায় এমন প্রোগ্রাম — একটি bKash-ধাঁচের টাকা পাঠানোর ফাংশন। এতে আছে নিজের তৈরি একটি exception (অংশ ৫-এ ব্যাখ্যা), raise (অংশ ৪), দুটি আলাদা except, আর else ও finally. তিনটি লেনদেনের ফল চালানোর আগে অনুমান করুন:

class InsufficientBalance(Exception):
    """ব্যালান্সের চেয়ে বেশি টাকা পাঠানোর চেষ্টা"""

def send_money(balance, amount):
    if amount <= 0:
        raise ValueError(f"অবৈধ পরিমাণ: {amount}")
    if amount > balance:
        raise InsufficientBalance(f"ব্যালান্স {balance}, চাওয়া {amount}")
    return balance - amount

for amount in (500, 5000, -20):
    try:
        left = send_money(1200, amount)
    except InsufficientBalance as e:
        print("ব্যর্থ:", e)
    except ValueError as e:
        print("ভুল ইনপুট:", e)
    else:
        print("সফল! বাকি", left)
    finally:
        print("-- লেনদেন শেষ:", amount)

finally আর with — পরিষ্কারের দুই পথ

finally-এর সবচেয়ে প্রচলিত কাজ হলো কোনো সম্পদ (resource) ফেরত দেওয়া। যেমন একটি ফাইল খুললে কাজ শেষে বন্ধ করতেই হবে, মাঝপথে ভুল হলেও:

f = open("report.txt", encoding="utf-8")
try:
    data = f.read()
finally:
    f.close()          # ভুল হলেও ফাইল বন্ধ হবে

এই ধাঁচ এত বেশি লাগে যে Python এর জন্য একটি ছোট রূপ দিয়েছে — with open(...) as f:. with ভেতরে ভেতরে ঠিক এই try/finally-এর কাজ করে। একে বলে context manager. পরের পর্বে (পর্ব ২৫) ফাইলের সাথে with প্রতিদিন ব্যবহার করবেন, আর এর ভেতরের যন্ত্রপাতি দেখবেন পর্ব ৩৬-এ।

৪ · raise — নিজে exception তোলা, আবার তোলা আর শিকল

এতক্ষণ Python নিজে exception তুলছিল। কিন্তু আপনার ফাংশনও বলতে পারে “এভাবে আমি কাজ করব না”. এর জন্য raise: raise ValueError("বয়স ঋণাত্মক হতে পারে না"). কখন তুলবেন? যখন ফাংশন তার প্রতিশ্রুত কাজ করতে পারছে না, আর কী করা উচিত সেই সিদ্ধান্ত তার নয়। অংশ ৩-এর send_money ঠিক এটাই করেছে।

ভালো বার্তা কেমন হয়

Exception-এর বার্তা পড়বেন আপনি নিজে, রাত দুটোয়, একটি লগ ফাইলে। তাই বার্তায় থাকা উচিত কী ভুল, কোন মানে ভুল, আর কী আশা করা হয়েছিল:

• দুর্বল: raise ValueError("invalid") — কোন জিনিস invalid? কোন মান?
• ভালো: raise ValueError(f"বয়স 0–119 হতে হবে, পেয়েছি {age}")

আর সঠিক ধরন বাছুন: মানটির type ঠিক কিন্তু মান অগ্রহণযোগ্য হলে ValueError; type-ই ভুল হলে TypeError; খোঁজা জিনিস না থাকলে KeyError/LookupError. সাধারণ Exception("...") তুলবেন না — তাহলে ডাকার জায়গা নির্দিষ্ট করে ধরতে পারে না।

খালি raise — দেখলাম, এবার ওপরে যাক

কখনো আপনি ভুলটি ধরতে চান শুধু কিছু একটা করার জন্য — লগ লেখা, অর্ধেক কাজ ফিরিয়ে নেওয়া — কিন্তু পুরো সামলানোর ক্ষমতা আপনার নেই। তখন except-এর ভেতরে শুধু raise লিখুন। এতে একই exception, তার আসল traceback-সহ, আবার ওপরে চলে যায়। একে বলে re-raise:

try:
    transfer(account, 5000)
except InsufficientBalance:
    print("লেনদেন বাতিল, ব্যালান্স আগের মতো")   # নিজের অংশ সেরে নিলাম
    raise                                       # বাকি সিদ্ধান্ত ওপরের কোডের

raise e না লিখে খালি raise কেন? দুটোই কাজ করে, কিন্তু খালি raise উদ্দেশ্য স্পষ্ট করে (“যা ছিল তা-ই পাঠাচ্ছি”), আর traceback-এ এই লাইনটি নতুন উৎস হিসেবে ঢুকে বিভ্রান্তি তৈরি করে না।

Exception-এর শিকল — raise ... from

আরেকটি সাধারণ পরিস্থিতি: নিচের স্তরের একটি ভুলকে ওপরের স্তরের ভাষায় অনুবাদ করা। ধরুন একটি অ্যাপের সেটিং একটি dict-এ আছে, আর "port" চাবিটি নেই। নিচের স্তরে এটি একটি KeyError, কিন্তু অ্যাপের ব্যবহারকারীর কাছে আসল কথা হলো “কনফিগারেশন অসম্পূর্ণ”. তাই আপনি KeyError ধরে নিজের ConfigError তোলেন — কিন্তু আসল কারণটি হারাতে চান না। এর জন্য exception chaining:

1def load_port(cfg):2    try:3        return int(cfg["port"])4    except KeyError as e:5        raise ConfigError("port সেটিং নেই") from e67load_port({"host": "localhost"})

পুরো traceback দেখতে এমন (ফাইলের পথ ছোট করা হয়েছে):

Traceback (most recent call last):
  File "app.py", line 3, in load_port
    return int(cfg["port"])
               ~~~^^^^^^^^
KeyError: 'port'

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "app.py", line 7, in <module>
    load_port({"host": "localhost"})
  File "app.py", line 5, in load_port
    raise ConfigError("port সেটিং নেই") from e
ConfigError: port সেটিং নেই

৫ · Exception-এর বংশতালিকা আর নিজের exception class

Python-এর সব exception একটি বংশবৃক্ষে সাজানো। প্রতিটি exception আসলে একটি class, আর প্রতিটি class কোনো না কোনো বড় class-এর subclass (class নিয়ে বিস্তারিত পর্ব ২৯-এ)। একে বলে exception hierarchy. নিচে এর গুরুত্বপূর্ণ অংশ (পুরো তালিকা অনেক বড়):

BaseException                  ← সবার আদি; সরাসরি ধরবেন না
 ├── KeyboardInterrupt         ← Ctrl+C
 ├── SystemExit                ← sys.exit()
 ├── GeneratorExit
 └── Exception                 ← "সাধারণ" সব ভুল এর নিচে
      ├── ArithmeticError
      │    ├── ZeroDivisionError
      │    └── OverflowError
      ├── LookupError
      │    ├── IndexError
      │    └── KeyError
      ├── ValueError
      │    └── UnicodeError
      ├── TypeError
      ├── AttributeError
      ├── NameError
      ├── OSError
      │    ├── FileNotFoundError
      │    └── PermissionError
      └── RuntimeError

এই গাছের নিয়ম একটি: except X ধরে X-কে এবং X-এর সব বংশধরকে. তাই except LookupError ধরবে IndexError আর KeyError দুটোই; except ArithmeticError ধরবে ZeroDivisionError. LookupError বা OSError-এর মতো মাঝের পরিবারগুলো কাজে লাগে যখন একটি পুরো শ্রেণির ভুলে একই আচরণ চান — যেমন ফাইল না পাওয়া, অনুমতি না থাকা বা ডিস্ক ভরে যাওয়া, সবই OSError.

সবচেয়ে নির্দিষ্টটি আগে

যেহেতু প্রথম মিলে যাওয়া except-ই চলে, সাধারণ ধরনটি ওপরে রাখলে নিচের নির্দিষ্টটি কখনো চলবে না:

try:
    price = int(text)
except Exception:          # সব ভুল এখানেই আটকে যায়
    print("কিছু একটা ভুল")
except ValueError:         # এই block কখনো চলবে না
    print("সংখ্যা লিখুন")

Python এখানে কোনো error দেয় না — কোডটি শুধু চুপচাপ ভুল আচরণ করে। নিয়ম: নির্দিষ্ট থেকে সাধারণ, ঠিক যেমন পর্ব ১১-এ কড়া শর্ত আগে রাখতে শিখেছিলেন।

নিজের exception — দুই লাইনের class

নিজের প্রোগ্রামের নিজস্ব ভুলের জন্য নিজের ধরন বানানো সবচেয়ে পরিষ্কার পথ। একে বলে custom exception. Class কী, তা পর্ব ২৯-এ শিখবেন; আপাতত এই ধাঁচটি মুখস্থ রাখলেই চলবে:

class WalletError(Exception):
    """এই ওয়ালেট অ্যাপের সব ভুলের আদি"""

class InsufficientBalance(WalletError):
    """ব্যালান্স কম"""

class DailyLimitExceeded(WalletError):
    """দিনের সীমা পার"""

তিনটি জিনিস লক্ষ করুন। প্রথমত, (Exception) লেখা মানে “এটি Exception পরিবারের সদস্য” — BaseException থেকে নয়, তাহলে সাধারণ except Exception একে ধরতে পারত না। দ্বিতীয়ত, body-তে শুধু একটি docstring — আর কিছু লাগে না; নাম আর পরিবারই আসল তথ্য। তৃতীয়ত, নাম শেষ হয় Error দিয়ে (PEP 8-এর পরামর্শ), যদিও InsufficientBalance-এর মতো স্পষ্ট নামও চলে। একটি অ্যাপের সব ভুলের একটি সাধারণ আদি (WalletError) রাখলে ব্যবহারকারী চাইলে except WalletError দিয়ে আপনার অ্যাপের সব ভুল একসাথে ধরতে পারেন, আবার চাইলে আলাদা করেও।

৬ · EAFP বনাম LBYL — অনুমতি চাওয়া, নাকি ক্ষমা চাওয়া?

ভুল সামলানোর দুটি দর্শন আছে। একটি হলো LBYL — “Look Before You Leap”, লাফ দেওয়ার আগে দেখে নাও: কাজের আগে if দিয়ে সব শর্ত পরীক্ষা করো। অন্যটি EAFP — “Easier to Ask for Forgiveness than Permission”, অনুমতি চাওয়ার চেয়ে ক্ষমা চাওয়া সহজ: কাজটি সরাসরি করো, না হলে exception ধরো। C-তে প্রথমটিই স্বাভাবিক; Python-এর অফিসিয়াল glossary দুটোকেই সংজ্ঞায়িত করে আর বলে EAFP হলো প্রচলিত Python ধাঁচ।

সবচেয়ে প্রতিদিনের উদাহরণ — একটি সেটিং dict থেকে "port" পড়া, না থাকলে 8080. নিচে দুই দর্শন পাশাপাশি, তারপর তৃতীয় একটি পথ:

1if "port" in config:2    port = config["port"]3else:4    port = 8080

1try:2    port = config["port"]3except KeyError:4    port = 8080

port = config.get("port", 8080)

কখন কোনটি

EAFP সবচেয়ে উজ্জ্বল যেখানে আগে থেকে পরীক্ষা করা কঠিন বা অসম্ভব। int() রূপান্তর এর সেরা উদাহরণ। একটি string পূর্ণসংখ্যা কি না, তা নিজে পরীক্ষা করতে গেলে ভাবতে হবে "-5", " 42 ", "1_000", এমনকি "৮০" — এর সবই int() গ্রহণ করে (হ্যাঁ, বাংলা অঙ্কও!)। অথচ "12.5" বা "৳80" গ্রহণ করে না। text.isdigit() দিয়ে পরীক্ষা করলে "-5" বাদ পড়বে, আর কিছু অদ্ভুত Unicode অঙ্ক পাস করে যাবে যেগুলো int() নেয় না। সবচেয়ে নির্ভরযোগ্য পরীক্ষক হলো int() নিজেই — তাই করে দেখুন, আর ValueError ধরুন।

ফাইলের ক্ষেত্রেও একই: if os.path.exists(path): open(path) লেখার মাঝে অন্য কোনো প্রোগ্রাম ফাইলটি মুছে দিতে পারে। try: open(path) আর except FileNotFoundError এই ফাঁক রাখে না। অন্যদিকে, LBYL ভালো যখন পরীক্ষাটি সস্তা আর ব্যর্থতা খুব সাধারণ ঘটনা — যেমন একটি তালিকা খালি কি না (if not items:) দেখা। আর এমন কাজের আগে, যা মাঝপথে থামলে অর্ধেক হয়ে থাকবে (দুটি অ্যাকাউন্টের একটি থেকে টাকা কেটে নেওয়ার পরে অন্যটিতে জমা দিতে না পারা), আগে যাচাই করে নেওয়াই বুদ্ধিমানের কাজ।

Exception কি ধীর? খরচের হিসাব

অনেকে C++ বা Java থেকে এসে ভাবেন exception খুব দামি। Python-এ হিসাবটি এমন: try block-এ ঢোকা প্রায় বিনামূল্যে — Python 3.11 থেকে CPython “zero-cost exception” ব্যবহার করে, অর্থাৎ ভুল না হলে try-এর জন্য কার্যত কোনো বাড়তি কাজ হয় না। খরচ হয় exception সত্যিই উঠলে — object তৈরি, traceback জোড়া, মিলে যাওয়া except খোঁজা। তবু Python-এর অন্য কাজের তুলনায় এই খরচ এত বড় নয় যে সাধারণ কোডে চিন্তা করতে হবে। ব্যবহারিক নিয়ম: যদি ব্যর্থতা বিরল হয় (বেশিরভাগ চাবি থাকে, বেশিরভাগ ইনপুট ঠিক), EAFP দ্রুত ও পরিষ্কার; যদি ব্যর্থতাই স্বাভাবিক ঘটনা হয় (অর্ধেক চাবিই নেই), .get() বা LBYL ভালো। আর সন্দেহ হলে মেপে দেখুন (পর্ব ৪৩)।

৭ · ইনপুট যাচাই, চুপচাপ গিলে ফেলা ভুল আর assert-এর সীমা

ভুল ইনপুটে আবার জিজ্ঞেস করা

পর্ব ১০-এ input() শিখেছিলেন, আর জেনেছিলেন এটি সবসময় string দেয়। ব্যবহারকারী বয়সের জায়গায় “বিশ” লিখলে int() ValueError দেবে। প্রোগ্রাম থেমে যাওয়ার বদলে ভদ্রভাবে আবার জিজ্ঞেস করাই ভালো। ধাঁচটি হলো: একটি অসীম while True লুপ, ভেতরে try, সফল হলে return বা break. এটি input validation-এর সবচেয়ে প্রচলিত রূপ।

নিচের প্রোগ্রামের দ্বিতীয় অংশে আরেকটি বাস্তব কাজ: একটি দোকানের দামের তালিকা, যেখানে কিছু দাম ঠিক, কিছু এলোমেলো। ভালোগুলো যোগ হবে, খারাপগুলো আলাদা তালিকায় জমবে — একটি খারাপ দামের জন্য পুরো হিসাব বাতিল হবে না:

def ask_age():
    while True:
        text = input("বয়স: ")
        try:
            age = int(text)
        except ValueError:
            print(f"'{text}' সংখ্যা নয়, আবার দিন")
            continue
        if 0 < age < 120:
            return age
        print(f"{age}? 1 থেকে 119-এর মধ্যে দিন")

print("ঠিক আছে:", ask_age())

prices, bad = [], []
for raw in ["120", "৮০", "45.5", "১২০ টাকা", "", "3,000"]:
    try:
        prices.append(float(raw))
    except ValueError:
        bad.append(raw)
print(sum(prices), bad)

লক্ষ করুন, try-এর ভেতরে শুধু একটি লাইন — যেটিতে ভুল হওয়ার কথা। সীমা-পরীক্ষা বাইরে, কারণ সেটি exception নয়, একটি সাধারণ সিদ্ধান্ত। আর খারাপ দামগুলো হারিয়ে যায়নি: bad তালিকায় জমা আছে, যাতে পরে কেউ দেখে ঠিক করতে পারে।

except: pass — সবচেয়ে বিপজ্জনক দুই লাইন

এবার উল্টো ছবি। নিচের কোডটি কখনো error দেখায় না — আর ঠিক সেটাই সমস্যা:

for row in rows:
    try:
        total += float(row["price"]) * row["qty"]
    except:
        pass               # ভুল হলে? চুপ!

এই অভ্যাসকে বলে exception swallowing — ভুল গিলে ফেলা। এখানে বানান ভুল (row["prcie"]), ভুল type, এমনকি Ctrl+C — সবই নিঃশব্দে হারিয়ে যাবে। মাসের শেষে হিসাব মিলবে না, আর কোথাও কোনো সূত্র থাকবে না। ক্র্যাশ করা প্রোগ্রাম অন্তত চিৎকার করে বলে কোথায় ভুল; চুপ থাকা প্রোগ্রাম ভুল ফল দিয়ে যায়। নিয়মগুলো:

• ভুল সামলাতে না জানলে ধরবেন না — ওপরে যেতে দিন।
• ধরলে, অন্তত লিখে রাখুন কী হয়েছে। প্রোডাকশনে এর জন্য logging module, যেটি পর্ব ৪০-এ শিখবেন; logging.exception("...") পুরো traceback-সহ লেখে।
• সত্যিই উপেক্ষা করার মতো নির্দিষ্ট ভুল হলে (যেমন “ফাইল আগে থেকেই নেই, মুছতে গিয়ে না পেলে সমস্যা নেই”) সেটি নাম ধরে লিখুন: contextlib.suppress(FileNotFoundError) বা except FileNotFoundError: pass — আর একটি comment দিন, কেন।

assert ইনপুট যাচাইয়ের জন্য নয়

পর্ব ১৩-এ assert দেখেছিলেন: assert amount > 0, "পরিমাণ ধনাত্মক হতে হবে". শর্ত মিথ্যা হলে AssertionError ওঠে। তাহলে ব্যবহারকারীর ইনপুট যাচাইয়ে এটি ব্যবহার করবেন না কেন? কারণ Python-কে -O (optimize) দিয়ে চালালে সব assert লাইন পুরোপুরি বাদ পড়ে যায় — যেন কখনো লেখাই হয়নি। তখন আপনার “যাচাই” আর হবে না, আর −৫০০০ টাকার লেনদেন ঢুকে পড়বে। assert হলো প্রোগ্রামারের নিজের জন্য নোট — “এটা কখনো মিথ্যা হওয়ার কথা নয়; হলে আমার কোডেই বাগ”. বাইরের ডেটা (ইনপুট, ফাইল, নেটওয়ার্ক) যাচাইয়ের জন্য if আর raise ValueError(...).

৮ · Python 3.11 আর তার পরে — একসাথে অনেক ভুল, নোট আর আরও ভালো traceback

ExceptionGroup আর except*

এতক্ষণ ধরে নিয়েছি, একবারে একটিই ভুল হয়। কিন্তু ধরুন একটি প্রোগ্রাম একসাথে দশটি ওয়েবসাইট থেকে দাম আনছে (পর্ব ৪২-এর asyncio দিয়ে)। তিনটি সাইট ব্যর্থ — একটি timeout, দুটি ভুল ডেটা। কোন ভুলটি তুলবেন? প্রথমটি তুললে বাকি দুটির খবর হারিয়ে যায়। এই সমস্যার সমাধানে Python 3.11-এ এসেছে ExceptionGroup — একটি exception, যার ভেতরে কয়েকটি exception একসাথে থাকে — আর তা ধরার নতুন লেখা except* (PEP 654):

try:
    raise ExceptionGroup("দুটি কাজ ব্যর্থ",
                         [ValueError("ভুল দাম"), TimeoutError("সাইট ধীর")])
except* ValueError as eg:
    print("ডেটার ভুল:", eg.exceptions)
except* TimeoutError as eg:
    print("সময়ের ভুল:", eg.exceptions)

সাধারণ except-এ শুধু একটি block চলে; except*-এ প্রতিটি মিলে যাওয়া block চলে, আর প্রতিটি পায় group-এর শুধু নিজের অংশটুকু। এখানে দুটো লাইনই ছাপা হবে। দৈনন্দিন স্ক্রিপ্টে এটি খুব কম লাগবে; তবে asyncio-র TaskGroup (৩.১১) ব্যবহার করলে এর সাথে দেখা হবেই।

আরও ভালো traceback — সংক্ষেপে

পর্ব ০৪-এ এর কিছু দেখেছিলেন; এখানে exception-এর দৃষ্টিতে একবার মিলিয়ে নিন:

• Python 3.10: NameError ও AttributeError-এ “Did you mean …?” পরামর্শ, আর অনেক SyntaxError-এর বার্তা অনেক স্পষ্ট।
• Python 3.11: লাইনের ভেতরে ঠিক কোন অংশে ভুল, তা ~~~^^^ দাগ দিয়ে দেখানো (PEP 657); add_note; ExceptionGroup; আর zero-cost try.
• Python 3.13: টার্মিনালে রঙিন traceback.
• Python 3.14: বন্ধনী ছাড়া except A, B: (PEP 758), আর finally-এর ভেতরে return/break/continue-এ সতর্কবার্তা (PEP 765).

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

AI-কে “robust কোড লিখে দাও” বললে সে প্রায়ই সবকিছু try দিয়ে মুড়ে দেয়। দেখতে নিরাপদ লাগে, কিন্তু বেশিরভাগ সময় এতে ভুলগুলো শুধু লুকিয়ে যায়। কারণ AI-এর প্রশিক্ষণের কোডে “কোনোভাবে চালু রাখো” ধাঁচের উদাহরণ প্রচুর, আর এমন কোড প্রথম পরীক্ষায় কখনো ব্যর্থ হয় না — ব্যর্থ হয় পরে, চুপচাপ:

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

• Ctrl+F দিয়ে except: আর pass খুঁজেছি; প্রতিটি except-এ একটি নির্দিষ্ট ধরন আছে
• প্রতিটি try block ছোট — শুধু ভুল-প্রবণ লাইন; বাকি কাজ else বা বাইরে
• যেখানে ভুল ধরা হয়েছে, সেখানে হয় সত্যিকারের সামলানো আছে, নয়তো লগ লিখে আবার raise
• নতুন exception তোলার সময় from e আছে, আসল কারণ হারায়নি
• except-এর ক্রম নির্দিষ্ট থেকে সাধারণ; কোনো block “অপ্রাপ্য” নয়
• ইনপুট যাচাইয়ে assert নেই; finally-এর ভেতরে return নেই
• নিজে একটি ভুল ইনপুট দিয়ে চালিয়ে দেখেছি — বার্তাটি বোধগম্য, আর প্রোগ্রাম ভুল ফল নিয়ে চুপচাপ এগোয়নি