پیمایش در دنیای پیچیده مدیریت خطا در زبان برنامهنویسی راست
مدیریت خطا در زبان راست (Rust) موضوعی است که اغلب باعث بحثهای پرشوری در میان توسعهدهندگان میشود. تیم توسعهدهنده پروژه iroh اخیراً سفر خود و دیدگاههای ارزشمندشان را پس از دستوپنجه نرم کردن با استراتژیهای مختلف مدیریت خطا به اشتراک گذاشتهاند و نگاهی عملگرایانه به گزینههای موجود و معاوضههای آنها ارائه دادهاند.
دو فلسفه غالب: `anyhow` در مقابل `thiserror`
جامعه توسعهدهندگان راست عمدتاً بر دو روش اصلی برای مدیریت خطاها توافق کردهاند:
- رویکرد `anyhow`: این روش از یک نوع خطای کلی و همهکاره استفاده میکند که قادر است هر نوع خطایی را در بر بگیرد. پیادهسازی آن فوقالعاده سریع است، ردپای پشته (backtrace) کاملی ارائه میدهد و افزودن زمینه (context) را آسان میسازد. این ویژگیها آن را برای برنامههای کاربردی که دغدغه اصلیشان اطلاع از وقوع خطا و داشتن اطلاعات دقیق برای اشکالزدایی است، ایدهآل میکند.
- رویکرد `thiserror`: این استراتژی شامل تعریف دقیق متغیرهای enum برای هر سناریوی خطای ممکن است. این کار منجر به تولید انواع خطای دقیق و قابل تطبیق (matchable) میشود که به مصرفکنندگان یک کتابخانه اجازه میدهد تا با خطاهای مختلف به شیوههای متفاوتی برخورد کنند. نویسندگان کتابخانهها اغلب این روش را برای ایجاد APIهای پایدار و قابل پیشبینی ترجیح میدهند.
راه سوم: مدل خطای IO در کتابخانه استاندارد
جالب اینجاست که یک مدل قدرتمند اما کمتر استفادهشده دقیقاً در کتابخانه استاندارد راست وجود دارد. نوع std::io::Error خطاها را به دو بخش تقسیم میکند: یک نوع خطا (Error Kind) (یک دسته کلی مانند «عدم دسترسی») و یک منبع خطا (Error Source) (زنجیره خطای اصلی با زمینه بیشتر). این رویکرد امکان تطبیق بر روی الگوهای سطح بالا را فراهم میکند در حالی که جزئیات سطح پایین را حفظ میکند و تعادل زیبایی بین دو رویکرد anyhow و thiserror برقرار میسازد.
چالش همیشگی: مشکل ردپای پشته (Backtrace)
یکی از بزرگترین منابع ناامیدی برای توسعهدهندگان، به دست آوردن ردپای پشته مناسب است، که عمدتاً به این دلیل است که راست هنوز انتشار ردپای پشته را در سیستم مدیریت خطای خود پایدار نکرده است. این مسئله منجر به یک انتخاب دشوار میشود:
- `anyhow` میتواند ردپای پشته کامل ارائه دهد زیرا کل زنجیره خطا را کنترل میکند.
- `thiserror`، هنگام مواجهه با خطاهای تو در تو، نمیتواند به طور قابل اعتمادی ردپای پشته را منتشر کند زیرا هر نوع خطای سفارشی باید از ردپای پشته درون خطاهایی که در بر میگیرد آگاه باشد.
این مانع فنی که ریشه در سیستم تریت (trait) راست دارد، توسعهدهندگان را مجبور میکند بین اپراتور ارگونومیک ? و داشتن ردپای پشته کامل یکی را انتخاب کنند. این یک مصالحه دشوار است که نویسندگان کتابخانهها باید با آن کنار بیایند.
یافتن راهحل با `snafu`
پس از آزمایشهای فراوان، تیم iroh یک راهحل ترکیبی قدرتمند پیدا کرد: کریت snafu. این کریت که به عنوان thiserror تقویتشده توصیف میشود، بهترینهای هر دو جهان را ارائه میدهد:
- انواع خطای مبتنی بر enum مشابه `thiserror`.
- امکان پیوست زمینه غنی و زنجیرهسازی خطا.
- ثبت خودکار ردپای پشته هنگام ایجاد خطا.
نوآوری کلیدی snafu توانایی آن در بستهبندی انواع خطاهای مختلف ضمن حفظ کل زنجیره ردپای پشته است که محدودیتهای تریت Into در راست را دور میزند. این بدان معناست که توسعهدهندگان میتوانند سرانجام خطاهای خاص و عمیقاً تو در تو را با یک ردپای پشته کامل برای اشکالزدایی مؤثر داشته باشند.
دستورالعملهای عملی برای خطاهای مشخص (Concrete Errors)
انتقال تیم iroh به snafu باعث شد تا چندین دستورالعمل برای نوشتن خطاهای ساختاریافته تدوین کنند:
- محدود کردن دامنه خطاها به توابع، نه ماژولها: به جای یک enum خطای بزرگ برای کل ماژول، ایجاد enumهای کوچکتر و مختص توابع (مانند `ConnectError` برای تابع `connect`) سلسلهمراتب و وضوح بهتری را فراهم میکند.
- استفاده از نامهای توصیفی برای enumها: نامگذاری یک enum به صورت `ParseError` به جای یک نام عمومی مانند `TicketError` بلافاصله به کاربر دامنه خطاهای احتمالی را اطلاع میدهد و وضوح API را بهبود میبخشد.
- گنجاندن یک متغیر `Custom` برای تریتهای عمومی: برای تریتهایی که کاربران میتوانند پیادهسازی کنند، ارائه یک متغیر خطای عمومی (مانند `User` یا `Custom`) به آنها اجازه میدهد تا خطاهای خاص خود را از طریق نوع خطای کتابخانه منتشر کنند.
پذیرش معاوضهها
در حالی که خطاهای ساختاریافته با snafu مزایای بیشماری دارند، به تلاش اولیه بیشتری نسبت به رویکرد سریع و آسان anyhow نیاز دارند. برای پر کردن این شکاف، بهویژه در تستها و مثالها، تیم iroh کریت n0-snafu را ایجاد کرد؛ یک ابزار کمکی که بخشی از حس ارگونومیک anyhow را هنگام کار با خطاهای snafu بازمیگرداند.
سفر تیم iroh نشان میدهد که هیچ راهحل یکسانی برای همه وجود ندارد. نکته کلیدی، آگاهی و عمدی بودن در مورد معاوضههاست. در حالی که جامعه راست به درستی بر استفاده از خطاهای ساختاریافته در کتابخانهها اصرار دارد، واقعیت عملگرایانه این است که پروژههای مختلف نیازهای متفاوتی دارند. هدف، یافتن یک سیستم مدیریت خطای افسانهای و بینقص نیست، بلکه پیادهسازی سیستمی است که به اندازه کافی خوب باشد، اهداف پروژه را برآورده کند و در نهایت، منتشر شود.
اطلاعات بیشتر را از منبع اصلی مطالعه کنید: بحث در Hacker News