آموزش ذن پایتون: خطاها هرگز نباید با سکوت رد شوند

June 2020

ویدیویی وجود ندارد

خطاها هرگز نباید با سکوت رد شوند Errors Should Never Pass Silently

پایتون از یک سیستم قوی برای مقابله با خطا پشتیبانی می کند، و ده ها Exception داخلی را ارائه میکند، اما غالباً درباره اینکه چه زمانی باید از این Exceptionها استفاده شود و چه موارد جدیدی ضروری است شک وجود دارد. راهنمایی های ارائه شده توسط این خط ذن پایتون بسیار ساده است ، اما مانند بسیاری از افراد دیگر ، زیر ظاهر این فلسفه نکات بسیار بیشتری وجود دارد.

 

اولین کار روشن شدن مفهوم Error و Exception است. حتی اگر این کلمات ، مانند بسیاری دیگر در دنیای محاسبات ، غالباً با معنای اضافی بارگذاری می شوند ، ارزش دیدن آنها به همانطور که در زبان عمومی استفاده می شود ، وجود دارد. تعاریف زیر را در نظر بگیرید:

این اصطلاحات در اینجا کنار گذاشته شده است تا نشان دهد چقدر دو تعریف می توانند مشابه باشند. در زندگی واقعی ، بزرگترین تفاوت مشاهده شده بین این دو اصطلاح ، شدت مشکلات ناشی از انحراف است. Exceptionها معمولاً کمتر مزاحم و در نتیجه قابل قبول تر تلقی می شوند ، اما Errorها یک چیز مشابه است: نقض نوعی انتظار. برای اهداف این بحث ، از اصطلاح "Exception" برای اشاره به هرگونه خروج از این هنجار استفاده می شود.

 

نکته‌ای که باید بدانید اینست که هر Exception یک Error نیست. برخی از آنها برای تقویت گزینه های جریان کد مانند استفاده از StopIteration استفاده می شوند. در زمان استفاده از کد، استثنائات راهی را برای نشان دادن اتفاقاتی که در درون یک تابع رخ داده است فراهم می کند ، حتی اگر این نشانه هیچ ارتباطی با مقدار بازده آن نداشته باشد.

 

این تفسیر توصیف Exception را به تنهایی غیرممکن می کند. آنها باید در چارچوبی قرار بگیرند که انتظار داریم نقض شود. هر وقت یک قطعه کد می نویسیم ، قول می دهیم که به روشی خاص کار کند. Exceptionها آن قول را می شکنند ، بنابراین باید درک کنیم چه نوع وعده هایی را می دهیم و چگونه می توان آنها را شکست. در function پایین قولی داده‌ایم که براحتی میتوان آن را شکست:

def validate(data):
    if data['username'].startswith('_'):
        raise ValueError("Username must not begin with an underscore.")

وعده بارز در اینحا متد validate است. اگر داده های ورودی معتبر باشد، تابع سکوت خواهد کرد و هیچ مقداری return نمیشود. نقض این قانون ، مانند نام کاربری که با یک underscore شروع می شود ، به صراحت به عنوان یک Exception مورد رفتار قرار می گیرد ، این کار را به خوبی نشان می دهد که اجازه نمی دهد خطاها در سکوت عبور کنند. صدا کردن یک Exception توجه را به شرایط جلب می کند و اطلاعات کافی را برای کدی که این عملکرد نامیده می شود فراهم می کند تا آنچه را که اتفاق افتاده است بفهمید.

 

نکته دشوار اینجاست که استثنائات دیگری که ممکن است مطرح شود را کنترل کنید. به عنوان مثال ، اگر dictionary داده حاوی یک کلید نام کاربری نباشد ، همانطور که عملکرد انتظار دارد ، پایتون یک KeyError را صدا میزند. اگر این کلید وجود داشته باشد ، اما مقدار آن رشته نیست ، پایتون هنگام تلاش برای دستیابی به روش startwith () یک AttributeError را بالا می برد. اگر داده ها اصلاً dictinary نباشند، پایتون یک TypeError را مطرح می کند.

 

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

 

با توجه به این نیاز جدید ، validate() را می توان کمی تغییر داد تا دیگر به وجود کلید کاربری متکی نباشید تا به درستی کار کند. با این وجود ، همه فرضیات دیگر باید دست نخورده باقی بمانند و در صورت نقض باید استثنائات مربوطه را مطرح کنند.در اینجا نحوه مراقبت از این تغییر آورده شده است

def validate(data):
    if 'username' in data and data['username'].startswith('_'):
        raise ValueError("Username must not begin with an underscore.")

و دقیقاً مانند آن ، یک فرض حذف شده است و اکنون عملکرد بدون عملکرد با نام کاربری موجود در دیکشنری داده می تواند درست کار کند. از طرف دیگر ، اکنون می توانید نام کاربری مفقود شده را صریحاً بررسی کرده و در صورت لزوم یک استثناء خاص تر را مطرح کنید.

ارسال نظر

اگر قراره سوالی بپرسید که داخلش کد هست، بهتره از کدتون عکس بگیرید و به ایمیلی که پایین نوشتم بفرستید