آموزش خطا و استثناسازه‌های اصلی برنامه

۰۱ خطای اصلی را در راه نگه دارید

وقتی یک خطای پایین‌سطح را به یک خطای بامعنی برای دامنه خودتان تبدیل می‌کنید، بند from را جا نیندازید:

• except ValueError as exc:
• raise RuntimeError("radif kharab") from exc

حالا e.__cause__ هنوز همان ValueError است و گزارش خطا هر دو را پشت سر هم چاپ می‌کند. بدون from، پایتون باز هم زنجیره را نگه می‌دارد ولی با عبارت «هنگام رسیدگی به خطای بالا خطای دیگری رخ داد» که یعنی این دومی اتفاقی بود. تفاوت بین «این را من ترجمه کردم» و «اینجا هم چیزی خراب شد» همین یک کلمه است، و کسی که لاگ را شش ماه بعد می‌خواند فقط همین را دارد.

۰۲ بلوک try فقط سطری را بگیرد که می‌تواند بشکند

وسوسه این است که کل تابع داخل یک try گذاشته شود. بهایش این است که وقتی خطا آمد، دیگر معلوم نیست از کدام سطر آمده: یک KeyError ممکن است از خواندن پیکربندی باشد یا از پاسخ سرویس، و بند except هر دو را یک جور رسیدگی می‌کند. یک try که فقط یک سطر در آن است، هم پیام دقیق‌تری می‌سازد و هم اجازه می‌دهد سطرهای بعدی خطای خودشان را داشته باشند.

دو بند دیگر همین ساختار کمتر نوشته می‌شوند و هر دو کار مشخصی دارند. else بدنه‌ای است که فقط وقتی اجرا می‌شود که هیچ خطایی نیامده باشد، و همان چیزی است که سطرهای بعدی را از داخل try بیرون می‌آورد. finally در هر حالت اجرا می‌شود، حتی وقتی خطا در حال بالا رفتن است، و ترتیب اجرایش از درونی‌ترین فراخوانی به بیرون است: برنامه چطور یادش می‌ماند باید کجا برگردد.

۰۳ جایی که کار گیر می‌کند، شبکه‌ای است که گاهی جواب می‌دهد

برنامه‌ای که از ایران به یک سرویس بیرونی وصل می‌شود، خرابی را به شکلی می‌بیند که در آموزش‌ها نیست: نه یک خطای تمیز، بلکه اتصالی که برقرار می‌شود و وسط پاسخ قطع می‌شود، یا نیم ساعت جواب می‌دهد و نیم ساعت نه. کسی که یک بار این را دیده، عادت می‌کند دور کل تماس یک except گشاد بگذارد و پیام «خطا در ارتباط» چاپ کند، و از آن به بعد یک کلید نامعتبر و یک وقفه زمانی و یک پاسخ ناقص هر سه یک پیام می‌گیرند. تشخیص همان‌جا از بین رفت. حداقل کاری که ارزشش را دارد این است که نوع خطا و متن اصلی‌اش در لاگ بماند، حتی وقتی چیزی که به کاربر نشان می‌دهید یک جمله ساده است.

۰۴ ابزار، و سالی که این حرف درست است

در سال ۲۰۲۶ ماژول traceback در کتابخانه استاندارد و رایگان است و traceback.format_exception کل زنجیره را با همان بندهای __cause__ به رشته می‌دهد؛ جای چاپ کردن str(e) در لاگ را گرفته، که فقط پیام آخرین خطا را دارد و نه اینکه از کجا آمده. برای اینکه از اول متن خطا و بستر آن با هم ثبت شوند، ماژول logging همان کتابخانه پرچم exc_info را دارد و همین یک آرگومان جای کپی کردن دستی گزارش خطا در پیام لاگ را می‌گیرد.

پرسش بعدی این است که وقتی این گزارش‌ها روی هم انباشته شدند چه چیزی از آن‌ها باید نگه داشته شود تا خرابی بعدی قابل تشخیص باشد، که چه چیزی ثبت شود تا خرابی بعدی قابل تشخیص باشد جوابش است، و خواندن خود گزارش مهارتی جداست: سطری که مهم است معمولاً سطر اول نیست. در سمت سرویس، همین انتخاب تعیین می‌کند کاربر چه کد وضعیتی می‌گیرد: قرارداد بین دو برنامه.