Python Try-Except ट्यूटोरियल: बेहतरीन प्रथाएँ और वास्तविक उदाहरण

जब Python कोड रनटाइम पर किसी समस्या से टकराता है, तो वह अक्सर एक exception उठाता है। यदि उसे हैंडल न किया जाए, तो exceptions आपका प्रोग्राम क्रैश कर देंगे। लेकिन try-except ब्लॉक्स के साथ, आप उन्हें पकड़ सकते हैं, सुव्यवस्थित रूप से रिकवर कर सकते हैं, और अपने एप्लिकेशन को चलते रख सकते हैं।

यह ट्यूटोरियल exceptions की मूल बातें नहीं है, हम इसे पहले ही अपनी Exception & Error Handling in Python गाइड में कवर कर चुके हैं। इसके बजाय, यहाँ हम व्यवहार में try-except पर गहराई से नज़र डालेंगे: अपने ब्लॉक्स को कैसे संरचित करें, आम गलतियों से कैसे बचें, और ऐसी बेहतरीन प्रथाएँ कैसे अपनाएँ जो आपके कोड को वास्तविक दुनिया के परिदृश्यों में अधिक भरोसेमंद बनाती हैं।

अंत तक, आप न केवल यह समझेंगे कि try-except कैसे काम करता है, बल्कि यह भी कि इसे Pythonic तरीके से कैसे उपयोग करना है; ऐसा एरर-हैंडलिंग कोड लिखना जो स्पष्ट, मेंटनेबल और प्रोडक्शन-रेडी हो।

यदि आप अभी भी Python सीखने की यात्रा पर हैं, तो मैं Python Programming Fundamentals स्किल ट्रैक देखने की सलाह दूँगा, जो आपको सभी ज़रूरी कौशल विकसित करने में मदद करेगा। 

try-except पर ध्यान क्यों दें?

Python में एरर हैंडलिंग का मूल उद्देश्य ऐसे प्रोग्राम डिजाइन करना है जो अनपेक्षित स्थितियों से निपट सकें। और जबकि एरर हैंडलिंग के लिए कई टूल हैं, try-except Python के दृष्टिकोण की रीढ़ है।

यह इतना महत्वपूर्ण क्यों है?

• यह Python के दर्शन को दर्शाता है। Python में प्रचलित शैली है EAFP; Easier to Ask Forgiveness than Permission। हर चीज़ पहले से जाँचने के बजाय (क्या यह फ़ाइल मौजूद है? क्या यह इनपुट वैध है? क्या सर्वर उपलब्ध है?), आप ऑपरेशन को बस आज़माते हैं। यदि वह विफल होता है, तो आप exception पकड़ते हैं और उसे संभालते हैं। इससे कोड छोटा और साफ होता है।
• यह वास्तविक दुनिया के वातावरण में कोड को चलता रखता है। उपयोगकर्ता इनपुट बिखरा हुआ होगा, फ़ाइलें गायब होंगी, APIs फेल होंगी, और नेटवर्क ड्रॉप होंगे। try-except के साथ, आप ऐसा कोड लिख सकते हैं जो पहली समस्या पर ढहने के बजाय समझदारी से प्रतिक्रिया दे।
• यह शुरुआती और पेशेवर दोनों के लिए पर्याप्त लचीला है। एक शुरुआती try-except का उपयोग ValueError पकड़ने के लिए कर सकता है जब इनपुट को integer में बदला जा रहा हो। एक प्रोडक्शन सिस्टम इसे एरर्स लॉग करने, विफल ऑपरेशन्स को पुनः प्रयास करने, या debugging आसान बनाने के लिए कस्टम exceptions उठाने में उपयोग कर सकता है।

इसीलिए यह लेख try-except पर ज़ूम करता है। इसे साध लेना उस फर्क को पैदा करता है जो स्क्रिप्ट्स के बीच होता है जो सिर्फ़ आदर्श स्थितियों में काम करती हैं और ऐसे सॉफ़्टवेयर के बीच जो मज़बूत, मेंटनेबल और प्रोडक्शन-रेडी है।

Try‑Except ब्लॉक की बनावट

सबसे सरल रूप में:

try:
    risky_thing()
except SomeError:
    handle_it()

जब Python को try ब्लॉक के अंदर कोई एरर मिलता है, तो वह प्रोग्राम क्रैश करने के बजाय मिलते-जुलते except ब्लॉक पर कूदता है।

आप इस पैटर्न को else और finally क्लॉज़ से भी बढ़ा सकते हैं:

try:
    do_something()
except ValueError:
    print("Bad value!")
else:
    print("All good.")
finally:
    clean_up()

यहाँ एक बुनियादी कार्यशील उदाहरण है:

try:
    x = int(input("Enter a number: "))
except ValueError:
    print("That wasn’t a number.")
else:
    print("You entered", x)
finally:
    print("Done.")

except एरर को हैंडल करता है, else केवल तभी चलता है जब सब कुछ ठीक रहा हो, और finally हमेशा चलता है, भले ही आप Ctrl‑C दबाएँ या बाहर निकलें।

आप Python में यूज़र इनपुट हैंडलिंग की बुनियादी से लेकर उन्नत वैलिडेशन और एरर-हैंडलिंग तकनीकों तक की समझ हमारे Python User Input: Handling, Validation, and Best Practices ट्यूटोरियल से सीख सकते हैं। 

एकाधिक Exceptions को हैंडल करना

कभी-कभी, एक except काफ़ी नहीं होता। अलग-अलग कोड पाथ अलग-अलग तरीकों से फेल हो सकते हैं, और एक खाली except: के साथ सब कुछ पकड़ लेना ज़्यादा मददगार नहीं है; यह बग्स छिपा सकता है और debugging को सिरदर्द बना सकता है।

मान लीजिए आप किसी चीज़ को integer में बदलकर फिर उसे divide करने की कोशिश कर रहे हैं। यह है जो नहीं करना चाहिए:

try:
    result = int(user_input) / 2
except:
    print("Something went wrong.")

यह सब कुछ पकड़ लेता है, जिनमें वे चीज़ें भी शामिल हैं जिन्हें आप शायद छिपाना नहीं चाहते, जैसे वैरिएबल नाम में टाइपो या अप्रत्याशित exceptions जो असली समस्याओं की ओर इशारा करते हैं।

इसके बजाय, विशिष्ट रहें:

try:
    result = int(user_input) / 2
except ValueError:
    print("That wasn't a number.")
except ZeroDivisionError:
    print("Division by zero?")

यदि आपके पास कई exception प्रकार हैं जिन्हें एक जैसा ट्रीट करना है, तो आप उन्हें इस तरह समूहित कर सकते हैं:

try:
    result = some_function()
except (TypeError, ValueError):
    print("Something was wrong with the data.")

इस तरह, आप अभी भी स्पष्ट रहते हैं कि क्या गलत हो सकता है, बिना एक ही ब्लॉक को बार-बार दोहराए।

और फिर आता है except Exception, जो एक खाली except से बेहतर है, लेकिन फिर भी बहुत चौड़ा है। आप जिन विशिष्ट एरर्स की उम्मीद करते हैं, उन्हें लक्षित करना बेहतर है।

else और finally ब्लॉक्स का उपयोग

जब try ब्लॉक के अंदर का कोड सफल होता है और कोई exception नहीं उठता, तो Python else ब्लॉक को चलाता है। 

try:
    user_id = get_user_id()
except LookupError:
    print("User not found.")
else:
    print("Welcome, user", user_id)

यह आपको exception-हैंडलिंग लॉजिक को हैप्पी पाथ से अलग रखने में मदद करता है, जिससे पढ़ना आसान हो जाता है।

फिर आता है finally। इसे फ़र्क नहीं पड़ता क्या हुआ; यह हर हाल में चलता है। Exception? फिर भी चलेगा। कोई exception नहीं? फिर भी चलेगा। प्रोग्राम Ctrl‑C से क्रैश? फिर भी चलेगा। क्लीनअप जैसी चीज़ों के लिए बढ़िया:

try:
    f = open("data.txt")
    process(f)
except IOError:
    print("Couldn’t open file.")
finally:
    f.close()

बस याद रखें, यदि फ़ाइल खुली ही नहीं, तो f मौजूद भी न हो, इसलिए सावधान रहें। फ़ाइलों के साथ काम करते समय आप Python का कॉन्टेक्स्ट मैनेजर (with open(...) as f:) उपयोग कर सकते हैं। यह अधिक सुरक्षित है।

यदि आप Python में KeyError  exception को प्रभावी ढंग से संभालने के लिए exception हैंडलिंग और एरर प्रिवेंशन जैसी प्रमुख तकनीकें सीखना चाहते हैं, तो मैं हमारे Python KeyError Exceptions and How to Fix Them ट्यूटोरियल की सिफारिश करता हूँ। 

Python try-except: बेहतरीन प्रथाएँ और आम गलतियाँ

सच कहें तो: try‑except ब्लॉक्स लिखना थोड़ी कला है। सही किया जाए, तो ये आपके प्रोग्राम को क्रैश होने से बचाते हैं। गलत किया जाए, तो ये बग्स को इतने गहरे दफ़न कर देते हैं कि आपको तब तक पता नहीं चलता जब तक ऐप क्रैश न हो जाए और उपयोगकर्ता शिकायत न करें।

यहाँ कुछ आदतें हैं जिन्हें अपनाना उपयोगी है:

try ब्लॉक्स को छोटा रखें। एक ही try में सौ पंक्तियों को न लपेटें। इससे समस्या का कारण ढूँढ़ना मुश्किल हो जाएगा। इसके बजाय, केवल वही कोड लपेटें जो फेल हो सकता है:

# Good
try:
    value = int(data)
except ValueError:
    print("Couldn’t convert.")

# Bad
try:
    # Tons of unrelated logic
    value = int(data)
    do_more()
    something_else()
except ValueError:
    print("Huh?")

यदि केवल आज़माकर एरर पकड़ना आसान है, तो कार्रवाई से पहले कंडिशन जाँचना अवॉयड करें। Python इसे EAFP कहता है, Easier to Ask Forgiveness than Permission। यदि आप यह जाँच रहे हैं कि फ़ाइल मौजूद है और फिर उसे खोल रहे हैं, तो आप एक रेस कंडीशन बना रहे हैं। इसके बजाय:

try:
    with open("file.txt") as f:
        content = f.read()
except FileNotFoundError:
    print("No file.")

यह पैटर्न एक आम समस्या से बचाता है जहाँ जाँच और ओपन कॉल के बीच फ़ाइल गायब हो सकती है। बस चीज़ आज़माएँ। अगर फेल हो, तो फेल्योर पकड़ें।

इसके अलावा, सब कुछ पकड़कर और कुछ भी न करके एरर्स को साइलेंस करने से बचें। ऐसा न करें:

try:
    something()
except:
    pass

जब तक आप वाकई न जानते हों कि आप क्या कर रहे हैं, यही वह जगह है जहाँ बग्स छिपते और बढ़ते हैं। यदि साइलेंस करना ही है, तो विशिष्ट रहें:

try:
    something()
except TimeoutError:
    # okay to ignore in this case
    pass

और एरर्स को कहीं लॉग करें। उन्हें पूरी तरह निगल लेने का मतलब है कि भविष्य में आपको पता नहीं चलेगा कि क्या गलत हुआ।

बिल्ट-इन बनाम कस्टम Exceptions

Python में ढेरों exceptions पहले से मौजूद हैं, और वे आश्चर्यजनक रूप से कई मामलों को कवर करते हैं। आप शायद पहले ही कुछ से टकरा चुके होंगे:

• ValueError: जब प्रकार सही हो लेकिन मान अवैध हो, जैसे int("hello")।
• TypeError: जब आप गलत प्रकार पर ऑपरेशन करने की कोशिश करते हैं, जैसे स्ट्रिंग और नंबर को जोड़ना।
• ZeroDivisionError: आपने सही समझा, शून्य से भाग देना।
• FileNotFoundError: ऐसी फ़ाइल खोलना जो मौजूद न हो।
• KeyError: जब डिक्शनरी में कोई key गायब हो।

ये उपयोगी हैं, और ज़्यादातर स्क्रिप्ट्स या ऐप्स में ये पर्याप्त से अधिक होते हैं। लेकिन कभी-कभी आप कुछ अधिक वर्णनात्मक उठाना चाहेंगे, ऐसा जो आपके प्रोजेक्ट की दुनिया में मायने रखता हो, सिर्फ़ Python की नहीं।

मान लीजिए आप एक ऐप लिख रहे हैं जो ऑनलाइन ऑर्डर्स प्रोसेस करता है, और आप तब एरर उठाना चाहते हैं जब कोई उपयोगकर्ता ऐसी चीज़ खरीदने की कोशिश करता है जो स्टॉक से बाहर है। आप ValueError का उपयोग कर सकते हैं, लेकिन वह थोड़ा सामान्य है। यह आपके कोड को पढ़ने वाले अगले व्यक्ति को नहीं बताता कि क्या हुआ।

यहीं कस्टम exceptions चमकते हैं।

class OutOfStockError(Exception):
    pass

def check_inventory(product_id):
    if not in_stock(product_id):
        raise OutOfStockError(f"Product {product_id} is out of stock.")

कस्टम exception बनाकर, आप अर्थ की एक परत जोड़ रहे हैं। आप अपने आप को अधिक नियंत्रण भी दे रहे हैं; आप सिर्फ़ इसी एक विशिष्ट स्थिति को पकड़ सकते हैं:

try:
    check_inventory("shirt-001")
except OutOfStockError:
    print("Sorry, that item is sold out.")

यह छोटी-सी बात है, लेकिन यह आपके कोड को समझना और मेंटेन करना आसान बनाती है, खासकर बड़े प्रोजेक्ट्स में। और यह लॉगिंग और मॉनिटरिंग के साथ अच्छा काम करता है, कस्टम exception नाम किसी धुंधले ValueError की तुलना में ढूँढ़ने में बहुत आसान होते हैं।

लॉगिंग, Re-Raising, और Exception Chaining

डिबगिंग के दौरान एक क्षण आता है: आप एक traceback देखते हैं, उसे घूरते हैं, और समझते हैं कि आपको बिल्कुल अंदाज़ा नहीं है कि क्यों कुछ विफल हुआ। यही वह जगह है जहाँ लॉगिंग आती है। यह सिर्फ़ एरर्स रिकॉर्ड करने के बारे में नहीं है, यह भविष्य के आप (या आपकी टीम) को यह समझने के लिए breadcrumbs देने के बारे में है कि क्या गलत हुआ।

मान लीजिए आप एक exception पकड़ रहे हैं और आगे बढ़ने से पहले उसे लॉग करना चाहते हैं:

import logging
logging.basicConfig(level=logging.ERROR)

try:
    do_something()
except ValueError as e:
    logging.error("Failed to do something: %s", e)
    raise

अंत में वह raise महत्वपूर्ण है, यह लॉग करने के बाद उसी exception को फिर से फेंक देता है। इसके बिना, आपने एरर को निगल लिया है। कभी-कभी यह ठीक है, लेकिन आमतौर पर नहीं।

फिर आता है raise from वाला तरीका। यह तब है जब आप एक एरर को संभाल रहे हैं लेकिन दूसरा उठाना है, और आप मूल एरर नहीं खोना चाहते। Python आपको उन्हें चेन करने देता है:

try:
    connect_to_database()
except TimeoutError as e:
    raise ConnectionError("Database unavailable.") from e

इस तरह, traceback पूरी कहानी बताता है। आपको नया ConnectionError मिलता है, लेकिन साथ ही वह TimeoutError भी दिखता है जिसने इसे जन्म दिया। 

आप मूल एरर को दबा भी सकते हैं (जो आपको आमतौर पर नहीं करना चाहिए) इस तरह:

raise ConnectionError("Just this error, nothing else.") from None

लेकिन जब तक आपके पास अच्छा कारण न हो, पूरी चेन को बनाए रखना सभी को समझने में मदद करता है कि क्या गलत हुआ और वह कैसे बढ़ता गया।

आप Python में लॉगिंग की बुनियादों के बारे में हमारे Logging in Python Tutorial से सीख सकते हैं। 

वास्तविक दुनिया के उदाहरण और उपयोग मामलों

एब्स्ट्रैक्ट में exception हैंडलिंग पर बात करना एक बात है, लेकिन जब आप इसे वास्तविक कोड में देखते हैं, तभी बात जमती है।

उदाहरण के लिए यूज़र इनपुट लें। किसी भी व्यक्ति से पूछिए जिसने कमांड-लाइन टूल या फॉर्म वैलिडेटर बनाया हो: उपयोगकर्ता सबसे अजीब चीज़ें दर्ज करेंगे। आप एक संख्या माँगते हैं? कोई “twelve.” टाइप कर देगा। या फ़ोन नंबर पेस्ट कर देगा। या बस Enter दबा देगा। होता है।

“क्या हो अगर” जाँचों की लंबी सूची लिखने के बजाय, आप यह कर सकते हैं:

while True:
    user_input = input("Enter a number: ")
    try:
        number = int(user_input)
        break
    except ValueError:
        print("Try again with a whole number.")

यह कोड कचरा इनपुट मिलने पर घबराता नहीं। यह उपयोगकर्ता से फिर से कोशिश करने को कहता है और तब तक लूप करता है जब तक सब ठीक न दिखे। हर एज केस के लिए if स्टेटमेंट्स लगाने से कहीं ज़्यादा साफ।

एक और उदाहरण: ऐसी फ़ाइल पढ़ना जो मौजूद न भी हो सकती है।

try:
    with open("config.json") as f:
        settings = f.read()
except FileNotFoundError:
    print("Missing config file. Using defaults.")
    settings = "{}"

यह जाँचने की ज़रूरत नहीं कि फ़ाइल है या नहीं। बस खोलने की कोशिश करें, और अगर फेल हो, तो आगे बढ़ें। यदि आप पहले से जाँचने की कोशिश करते (os.path.exists()), तो कोई और जाँच और ओपन के बीच फ़ाइल हटा सकता था। यह एक रेस कंडीशन है, जिसे आप डिबग नहीं करना चाहेंगे।

नेटवर्क रिक्वेस्ट्स exceptions का एक और बड़ा स्रोत हैं। आप हमेशा इंटरनेट पर भरोसा नहीं कर सकते। सर्वर डाउन हो जाते हैं। कनेक्शन ड्रॉप हो जाते हैं। DNS फेल हो जाता है। तो यदि आप कुछ ऐसा कर रहे हैं:

import requests

try:
    response = requests.get("https://example.com/data")
    response.raise_for_status()
except requests.exceptions.RequestException as e:
    print("Network problem:", e)

वह RequestException बेस क्लास सुविधाजनक रूप से लगभग हर चीज़ पकड़ता है जो requests उठा सकता है, टाइमआउट से लेकर खराब रिस्पॉन्स तक। जब तक आप उन्हें अलग-अलग तरीके से हैंडल नहीं करना चाहते, आपको दस अलग except ब्लॉक्स लिखने की ज़रूरत नहीं।

और यदि आप ऑटोमेशन स्क्रिप्ट्स या बैकएंड सर्विसेज लिख रहे हैं, तो मुख्य लॉजिक को try‑except ब्लॉक्स में लपेटना इस फ़र्क का कारण बन सकता है कि एक टास्क फेल हो या पूरा सिस्टम अंधेरे में चला जाए। आप चाहते हैं कि एरर्स लॉग हों, रिकवर हो सकने वाले टास्क्स को फिर से आज़माया जाए, और जो रिकवर न हों उन्हें साफ़ तरीके से शट डाउन किया जाए—लॉग्स पर अनंत तक स्क्रॉल होती रहस्यमयी स्टैक ट्रेसेज़ नहीं।

Python ऑटोमेशन के बारे में—बुनियादी अवधारणाएँ, प्रमुख लाइब्रेरीज़, डेटा के साथ काम, AI एन्हांसमेंट्स और बेहतरीन प्रथाएँ—हमारे Python Automation: A Complete Guide ट्यूटोरियल से सीखें। 

Try-except Python के उन्नत उपयोग

अब तक, आपने शायद देख लिया होगा कि try‑except कितना लचीला हो सकता है। लेकिन लचीलापन दोधारी तलवार है। अनजाने में मददगार से लापरवाही तक जाना आसान है। यहाँ है कि चीज़ों को कैसे काबू में रखें।

विशिष्ट exceptions पकड़ें। यदि आपको पता है कि क्या गलत हो सकता है, तो उसका नाम लें:

try:
    result = int(data)
except ValueError:
    # Only catches invalid numbers, not everything else under the sun

खाली except: से बचें। इसे तब तक न करें जब तक आप कुछ बहुत विशेष हैंडल नहीं कर रहे। यह KeyboardInterrupt, SystemExit, और अन्य चीज़ों को भी पकड़ लेगा जिन्हें आप शायद साइलेंस नहीं करना चाहेंगे।

else और finally का उपयोग तब करें जब वे कोड को स्पष्ट बनाते हों। केवल इसलिए उन्हें न ठूँसें कि वे मौजूद हैं। यदि आपके कोड का सामान्य पाथ try के अंदर दब रहा है, तो उसे else में ले जाएँ।

अपने try ब्लॉक्स छोटे रखें। जितना अधिक आप इसमें शामिल करेंगे, यह पता लगाना उतना ही कठिन होगा कि एरर किस पंक्ति से आया। केवल उसी हिस्से को लपेटें जो फेल हो सकता है। 

ज़रूरत पड़ने पर एरर्स लॉग करें, खासकर प्रोडक्शन में। भले ही आप क्रैश न कर रहे हों, क्या (और कब) फेल हुआ यह जानना बाद में डिबगिंग को बहुत आसान बना देता है।

कस्टम exceptions अनिवार्य नहीं हैं, लेकिन वे मदद करते हैं। यदि आपके पास ऐप-विशिष्ट समस्याएँ हैं, तो अपने errors परिभाषित करें। वे लॉग्स को अधिक पढ़ने योग्य बना सकते हैं और आपके कोड को अधिक आत्मव्याख्यात्मक।

एक आखिरी बात: फ्लो कंट्रोल के लिए exceptions का उपयोग न करें जब तक कोई बेहतर तरीका न हो। “इसे आज़माओ; यदि यह फेल हो, तो वह करो” जैसी लॉजिक लिखना लुभा सकता है, लेकिन यदि ऐसा कुछ है जो अक्सर होना तय है, तो शायद कोई साफ़ तरीका मौजूद है।

निष्कर्ष

जैसा कि मैंने पूरे लेख में समझाया, exception हैंडलिंग केवल क्रैश से बचने के बारे में नहीं है। यह ऐसा कोड लिखने के बारे में है जो दिक्कतों की उम्मीद रखता है, उन्हें बिना हो-हंगामे के संभालता है, और आगे बढ़ता रहता है—या ऐसे तरीके से बंद होता है जो समझ में आता है। यह उस फ़र्क को दर्शाता है जहाँ उपयोगकर्ता को एक मददगार संदेश मिलता है बनाम उसे लंबे, अपठनीय traceback के साथ टर्मिनल पर वापस फेंक दिया जाता है।

मैं exceptions के बारे में हाथों-हाथ अभ्यासों के साथ और सीखने की दृढ़ता से सलाह देता हूँ, हमारे OOP in Python कोर्स के Catching Exceptions in Python अध्याय में।