पायथन अपवादों को अब पैटर्न-विरोधी माना जाता है

अपवाद क्या हैं? नाम से यह स्पष्ट है - वे तब उठते हैं जब कार्यक्रम में कोई अपवाद होता है। आप पूछ सकते हैं कि अपवाद एक प्रतिमान क्यों हैं, और वे टाइपिंग से कैसे संबंधित हैं? मैंने इसका पता लगाने की कोशिश की, और अब मैं आपसे इस बारे में चर्चा करना चाहता हूं।

अपवाद मुद्दे

हर दिन आपके सामने जो भी खामियां हैं, उन्हें ढूंढना मुश्किल है। आदत और अंधापन कीड़े को सुविधाओं में बदल देते हैं, लेकिन आइए अपवादों को खुले दिमाग से देखने की कोशिश करें।

अपवाद स्पॉट करना मुश्किल है

दो प्रकार के अपवाद हैं: "स्पष्ट" उस कोड को सीधे कॉल करके बनाया जाता है जिसे आप पढ़ रहे हैं; "हिडन" उपयोग किए गए कार्यों, कक्षाओं, विधियों में छिपे हुए हैं।

समस्या यह है कि "छिपे हुए" अपवाद वास्तव में नोटिस करना मुश्किल है। मैं आपको एक शुद्ध कार्य का एक उदाहरण दिखाता हूं:

 def divide(first: float, second: float) -> float: return first / second 

फ़ंक्शन केवल एक संख्या को दूसरे द्वारा विभाजित करता है, एक float लौटाता है। प्रकारों की जाँच की जाती है और आप कुछ इस तरह से चला सकते हैं:

 result = divide(1, 0) print('x / y = ', result) 

क्या आपने गौर किया है? वास्तव में, कार्यक्रम का निष्पादन कभी भी print तक नहीं पहुंचेगा, क्योंकि 1 को 0 से विभाजित करना एक असंभव ऑपरेशन है, यह एक ZeroDivisionError । हां, ऐसा कोड सुरक्षित है, लेकिन इसे वैसे भी उपयोग नहीं किया जा सकता है।

इस तरह के एक सरल और पठनीय कोड में एक संभावित समस्या पर ध्यान देने के लिए, एक अनुभव की आवश्यकता होती है। पायथन में कुछ भी विभिन्न प्रकार के अपवादों के साथ काम करना बंद कर सकता है: विभाजन, फ़ंक्शन कॉल, int , str , जनरेटर, लूप में पुनरावृत्तियों, विशेषताओं या कुंजियों तक पहुंच। यहां तक raise something() दुर्घटना का कारण बन सकता है। इसके अलावा, मैं इनपुट और आउटपुट संचालन का भी उल्लेख नहीं करता हूं। और चेक किए गए अपवादों को अब निकट भविष्य में समर्थित नहीं किया जाएगा।

जगह में सामान्य व्यवहार को बहाल करना संभव नहीं है

लेकिन इस तरह के एक मामले के लिए, हमारे पास अपवाद हैं। चलो बस ZeroDivisionError और कोड सुरक्षित हो जाएगा।

 def divide(first: float, second: float) -> float: try: return first / second except ZeroDivisionError: return 0.0 

अब सब ठीक है। लेकिन हम 0 क्यों लौटाते हैं? 1 या None क्यों नहीं? बेशक, ज्यादातर मामलों में, अपवाद के रूप में None प्राप्त None लगभग उतना ही बुरा (यदि बदतर नहीं है), लेकिन फिर भी आपको फ़ंक्शन का उपयोग करने के लिए व्यावसायिक तर्क और विकल्पों पर भरोसा करने की आवश्यकता है।

हम वास्तव में क्या साझा कर रहे हैं? मनमानी संख्या, कोई विशिष्ट इकाई या धन? हर विकल्प को आसान और बहाल करना आसान नहीं है। यह पता लग सकता है कि अगली बार जब आप एक फ़ंक्शन का उपयोग करते हैं, तो यह पता चलता है कि आपको एक अलग पुनर्प्राप्ति तर्क की आवश्यकता है।

दुखद निष्कर्ष: प्रत्येक समस्या का समाधान व्यक्तिगत है, जो उपयोग के विशिष्ट संदर्भ पर निर्भर करता है।

ZeroDivisionError एक बार और सभी के लिए निपटने के लिए कोई चांदी की गोली नहीं है। और हम बार-बार अनुरोधों और टाइमआउट के साथ जटिल I / O की संभावना के बारे में बात नहीं कर रहे हैं।

शायद अपवादों को संभालना आवश्यक नहीं है, जहाँ वे उत्पन्न होते हैं? शायद बस इसे कोड निष्पादन प्रक्रिया में फेंक दें - कोई इसे बाद में पता लगाएगा। और फिर हम वर्तमान मामलों की स्थिति में लौटने के लिए मजबूर हो जाते हैं।

निष्पादन की प्रक्रिया अस्पष्ट है

ठीक है, चलो आशा करते हैं कि कोई अन्य व्यक्ति अपवाद को पकड़ता है और शायद इसे संभालता है। उदाहरण के लिए, सिस्टम उपयोगकर्ता को दर्ज किए गए मान को बदलने के लिए कह सकता है, क्योंकि इसे 0. से divide नहीं किया जा सकता है और त्रुटि से उबरने के लिए divide कार्य स्पष्ट रूप से जिम्मेदार नहीं होना चाहिए।

इस मामले में, आपको यह जाँचने की आवश्यकता है कि हमने अपवाद कहाँ पकड़ा है। वैसे, यह कैसे निर्धारित किया जाए कि यह कहां संसाधित किया जाएगा? क्या कोड में सही जगह पर जाना संभव है? यह पता चला है कि यह असंभव है ।

यह निर्धारित करना संभव नहीं है कि अपवाद फेंके जाने के बाद कोड की कौन सी लाइन निष्पादित होगी। विकल्पों except विभिन्न प्रकार के अपवादों को अलग-अलग तरीके से संभाला जा सकता है और कुछ अपवादों को अनदेखा किया जा सकता है । और आप अन्य मॉड्यूल में अतिरिक्त अपवाद फेंक सकते हैं जो पहले निष्पादित किए जाएंगे, और सामान्य तौर पर सभी तर्क को तोड़ देंगे।

मान लीजिए कि एक आवेदन में दो स्वतंत्र धागे हैं: एक नियमित धागा जो ऊपर से नीचे तक चलता है, और एक अपवाद धागा जो इसे पसंद करता है, चलता है। इस कोड को कैसे पढ़ें और समझें?

केवल डिबगर "कैच ऑल अपवाद" मोड में चालू हुआ।


अपवाद, कुख्यात goto तरह, कार्यक्रम संरचना को फाड़ देते हैं।

अपवाद अनन्य नहीं हैं

आइए एक और उदाहरण देखें: सामान्य दूरस्थ HTTP API एक्सेस कोड:

 import requests def fetch_user_profile(user_id: int) -> 'UserProfile': """Fetches UserProfile dict from foreign API.""" response = requests.get('/api/users/{0}'.format(user_id)) response.raise_for_status() return response.json() 

इस उदाहरण में, शाब्दिक रूप से सब कुछ गलत हो सकता है। यहां संभावित त्रुटियों की आंशिक सूची दी गई है:

• नेटवर्क उपलब्ध नहीं हो सकता है और अनुरोध को निष्पादित नहीं किया जाएगा।
• सर्वर काम नहीं कर सकता है।
• सर्वर बहुत व्यस्त हो सकता है, टाइमआउट होगा।
• सर्वर को प्रमाणीकरण की आवश्यकता हो सकती है।
• API में ऐसा URL नहीं हो सकता है।
• एक गैर-मौजूद उपयोगकर्ता को स्थानांतरित किया जा सकता है।
• पर्याप्त अधिकार नहीं हो सकते।
• आपके अनुरोध को संसाधित करते समय आंतरिक त्रुटि के कारण सर्वर क्रैश हो सकता है
• सर्वर अमान्य या क्षतिग्रस्त प्रतिक्रिया लौटा सकता है।
• सर्वर अमान्य JSON लौटा सकता है जिसे पार्स नहीं किया जा सकता है।

सूची आगे और आगे बढ़ती है, इसलिए कई संभावित समस्याएं दुर्भाग्यपूर्ण तीन लाइनों के कोड में होती हैं। हम कह सकते हैं कि यह आम तौर पर केवल एक भाग्यशाली मौका से काम करता है, और अपवाद के साथ गिरने की संभावना अधिक है।

खुद की सुरक्षा कैसे करें?

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

• except Exception: pass हर जगह लिखें except Exception: pass । मृत अंत। ऐसा न करें।
• None लौटा। बहुत दुष्ट। नतीजतन, आपको या तो लगभग हर पंक्ति को शुरू करना होगा if something is not None: और सभी तर्क सफाई चेक के कचरे के पीछे खो जाएंगे, या आप हर समय TypeError से पीड़ित होंगे। अच्छा विकल्प नहीं है।
• विशेष उपयोग के मामलों के लिए कक्षाएं लिखें। उदाहरण के लिए, UserNotFound और MissingUser जैसी त्रुटियों के लिए उपवर्गों के साथ आधार वर्ग User । इस दृष्टिकोण का उपयोग कुछ विशिष्ट परिस्थितियों में किया जा सकता है, जैसे कि Django में बेनामीसियर, लेकिन कक्षाओं में सभी संभावित त्रुटियों को लपेटना अवास्तविक है। यह बहुत अधिक काम लेगा और डोमेन मॉडल अकल्पनीय रूप से जटिल हो जाएगा।
• एक आवरण में परिणामी चर या त्रुटि मान को लपेटने के लिए कंटेनरों का उपयोग करें और कंटेनर मूल्य के साथ काम करना जारी रखें। यही कारण है कि हमने @dry-python/return प्रोजेक्ट बनाया। ताकि फ़ंक्शंस कुछ सार्थक, टाइप और सुरक्षित वापस लौटें।

आइए हम विभाजन के उदाहरण पर लौटते हैं, जो एक त्रुटि होने पर 0 देता है। क्या हम स्पष्ट रूप से संकेत दे सकते हैं कि विशिष्ट संख्यात्मक मान लौटाए बिना फ़ंक्शन सफल नहीं हुआ?

 from returns.result import Result, Success, Failure def divide(first: float, second: float) -> Result[float, ZeroDivisionError]: try: return Success(first / second) except ZeroDivisionError as exc: return Failure(exc) 

हम दो आवरणों में से एक में मानों को शामिल करते हैं: Success या Failure । इन वर्गों को Result आधार वर्ग से विरासत में मिला है। पैक किए गए मानों के प्रकार एनोटेशन में दिए गए फ़ंक्शन के साथ निर्दिष्ट किए जा सकते हैं, उदाहरण के लिए, Result[float, ZeroDivisionError] रिटर्न या तो Success[float] या Failure[ZeroDivisionError] ।

यह हमें क्या देता है? अधिक अपवाद असाधारण नहीं हैं, लेकिन अपेक्षित समस्याएं हैं । इसके अलावा, Failure में एक अपवाद लपेटने से एक दूसरी समस्या हल हो जाती है: संभावित अपवादों की पहचान करने की जटिलता।

 1 + divide(1, 0) # => mypy error: Unsupported operand types for + ("int" and "Result[float, ZeroDivisionError]") 

अब उन्हें स्पॉट करना आसान है। यदि आप कोड में Result देखते हैं, तो फ़ंक्शन अपवाद छोड़ सकता है। और आप पहले से उसका प्रकार भी जानते हैं।

इसके अलावा, लाइब्रेरी पूरी तरह से टाइप की गई है और PEP561 के साथ संगत है । यदि आप घोषित प्रकार से मेल नहीं खाने वाले किसी चीज़ को वापस करने का प्रयास करते हैं, तो मैपी आपको चेतावनी देगा।

 from returns.result import Result, Success, Failure def divide(first: float, second: float) -> Result[float, ZeroDivisionError]: try: return Success('Done') # => error: incompatible type "str"; expected "float" except ZeroDivisionError as exc: return Failure(0) # => error: incompatible type "int"; expected "ZeroDivisionError" 

कंटेनरों के साथ कैसे काम करें?

दो तरीके हैं :

• सामान्य मानों को लौटाने वाले कार्यों के लिए map ;
• अन्य कंटेनरों को लौटाने वाले कार्यों के लिए bind ।

 Success(4).bind(lambda number: Success(number / 2)) # => Success(2) Success(4).map(lambda number: number + 1) # => Success(5) 

सुंदरता यह है कि यह कोड आपको असफल स्क्रिप्ट से बचाएगा, क्योंकि .bind और .map Failure कंटेनर के लिए निष्पादित नहीं करेगा:

 Failure(4).bind(lambda number: Success(number / 2)) # => Failure(4) Failure(4).map(lambda number: number / 2) # => Failure(4) 

अब आप केवल सही निष्पादन प्रक्रिया पर ध्यान केंद्रित कर सकते हैं और सुनिश्चित कर सकते हैं कि गलत राज्य अप्रत्याशित स्थान पर कार्यक्रम को नहीं तोड़ देगा। और हमेशा गलत स्थिति का निर्धारण करने, इसे सही करने और प्रक्रिया के संकल्पित मार्ग पर वापस लौटने का अवसर होता है।

 Failure(4).rescue(lambda number: Success(number + 1)) # => Success(5) Failure(4).fix(lambda number: number / 2) # => Success(2) 

हमारे दृष्टिकोण में, "सभी समस्याओं को व्यक्तिगत रूप से हल किया जाता है," और "निष्पादन प्रक्रिया अब पारदर्शी है।" प्रोग्रामिंग का आनंद लें जो रेल पर सवारी करता है!

लेकिन कंटेनरों से मूल्यों का विस्तार कैसे करें?

वास्तव में, यदि आप ऐसे कार्यों के साथ काम करते हैं जो कंटेनरों के बारे में कुछ भी नहीं जानते हैं, तो आपको स्वयं मूल्यों की आवश्यकता है। तब आप .unwrap() या .value_or() विधियों का उपयोग कर सकते हैं:

 Success(1).unwrap() # => 1 Success(0).value_or(None) # => 0 Failure(0).value_or(None) # => None Failure(1).unwrap() # => Raises UnwrapFailedError() 

रुको, हमें अपवादों से छुटकारा पाना था, और अब यह पता चला है कि सभी .unwrap() कॉल दूसरे अपवाद को जन्म दे सकती हैं?

UnwrapFailedErrors के बारे में कैसे नहीं सोचा जाए?

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

 from returns.result import Result, Success, Failure class CreateAccountAndUser(object): """Creates new Account-User pair.""" # TODO: we need to create a pipeline of these methods somehow... def _validate_user( self, username: str, email: str, ) -> Result['UserSchema', str]: """Returns an UserSchema for valid input, otherwise a Failure.""" def _create_account( self, user_schema: 'UserSchema', ) -> Result['Account', str]: """Creates an Account for valid UserSchema's. Or returns a Failure.""" def _create_user( self, account: 'Account', ) -> Result['User', str]: """Create an User instance. If user already exists returns Failure.""" 

सबसे पहले, आपको अपने स्वयं के व्यावसायिक तर्क में मूल्यों का विस्तार नहीं करना है:

 class CreateAccountAndUser(object): """Creates new Account-User pair.""" def __call__(self, username: str, email: str) -> Result['User', str]: """Can return a Success(user) or Failure(str_reason).""" return self._validate_user( username, email, ).bind( self._create_account, ).bind( self._create_user, ) # ... 

सब कुछ बिना किसी समस्या के काम करेगा, कोई अपवाद नहीं .unwrap() जाएगा, क्योंकि .unwrap() उपयोग नहीं किया जाता है। लेकिन क्या ऐसे कोड को पढ़ना आसान है? नहीं। और विकल्प क्या है? @pipeline :

 from result.functions import pipeline class CreateAccountAndUser(object): """Creates new Account-User pair.""" @pipeline def __call__(self, username: str, email: str) -> Result['User', str]: """Can return a Success(user) or Failure(str_reason).""" user_schema = self._validate_user(username, email).unwrap() account = self._create_account(user_schema).unwrap() return self._create_user(account) # ... 

अब यह कोड अच्छी तरह से पढ़ा जाता है। यहां बताया गया है कि कैसे .unwrap() और @pipeline एक साथ काम करते हैं: जब भी कोई .unwrap() विधि विफल होती है और Failure[str] , @pipeline डेकोरेटर उसे पकड़ता है और परिणामी मान के रूप में Failure[str] को लौटाता है। इस तरह से मैं कोड से सभी अपवादों को हटाने और इसे वास्तव में सुरक्षित और टाइप करने का प्रस्ताव देता हूं।

यह सब एक साथ लपेटें

ठीक है, अब हम HTTP एपीआई अनुरोध के साथ, नए उपकरण लागू करेंगे। याद रखें कि प्रत्येक पंक्ति एक अपवाद फेंक सकती है? और Result कंटेनर को वापस करने के लिए उन्हें प्राप्त करने का कोई तरीका नहीं है। लेकिन आप असुरक्षित कार्यों को लपेटने और उन्हें सुरक्षित बनाने के लिए @ सुरक्षित डेकोरेटर का उपयोग कर सकते हैं। नीचे दो कोड विकल्प दिए गए हैं जो समान कार्य करते हैं:

 from returns.functions import safe @safe def divide(first: float, second: float) -> float: return first / second # is the same as: def divide(first: float, second: float) -> Result[float, ZeroDivisionError]: try: return Success(first / second) except ZeroDivisionError as exc: return Failure(exc) 

@safe साथ पहला, पढ़ना आसान और बेहतर है।

एपीआई अनुरोध उदाहरण में करने के लिए आखिरी चीज @safe डेकोरेटर को जोड़ना है। परिणाम निम्नलिखित कोड है:

 import requests from returns.functions import pipeline, safe from returns.result import Result class FetchUserProfile(object): """Single responsibility callable object that fetches user profile.""" #: You can later use dependency injection to replace `requests` #: with any other http library (or even a custom service). _http = requests @pipeline def __call__(self, user_id: int) -> Result['UserProfile', Exception]: """Fetches UserProfile dict from foreign API.""" response = self._make_request(user_id).unwrap() return self._parse_json(response) @safe def _make_request(self, user_id: int) -> requests.Response: response = self._http.get('/api/users/{0}'.format(user_id)) response.raise_for_status() return response @safe def _parse_json(self, response: requests.Response) -> 'UserProfile': return response.json() 

अपवाद से छुटकारा पाने और कोड को सुरक्षित करने के लिए संक्षेप में :

• उन सभी तरीकों के लिए @safe रैपर का उपयोग करें जो एक अपवाद को फेंक सकते हैं। यह Result[OldReturnType, Exception] प्रकार को बदल देगा Result[OldReturnType, Exception] ।
• मूल्यों और त्रुटियों को एक सरल अमूर्तता में स्थानांतरित करने के लिए एक कंटेनर के रूप में Result उपयोग करें।
• कंटेनर से मूल्य का विस्तार करने के लिए .unwrap() का उपयोग करें।
• पढ़ने के लिए आसान .unwrap कॉल .unwrap बनाने के लिए .unwrap @pipeline का उपयोग करें।

इन नियमों का पालन करके, हम एक ही काम कर सकते हैं - केवल सुरक्षित और अच्छी तरह से पठनीय। अपवादों के साथ होने वाली सभी समस्याओं का समाधान किया गया था:

• "अपवाद स्पॉट के लिए कठिन हैं । " अब वे एक टाइप किए गए Result कंटेनर में लिपटे हुए हैं, जो उन्हें पूरी तरह से पारदर्शी बनाता है।
• "जगह में सामान्य व्यवहार को बहाल करना असंभव है । " अब आप कॉल करने वाले को पुनर्प्राप्ति प्रक्रिया को सुरक्षित रूप से सौंप सकते हैं। ऐसे मामले के लिए, .fix() और .rescue() ।
• "निष्पादन का क्रम अस्पष्ट है । " अब वे सामान्य व्यवसाय प्रवाह के साथ एक हैं। शुरू से अंत तक।
• "अपवाद असाधारण नहीं हैं । " हम जानते हैं! और हम उम्मीद करते हैं कि कुछ गलत होगा और किसी भी चीज के लिए तैयार होगा।

मामलों और सीमाओं का उपयोग करें

जाहिर है, आप अपने सभी कोड में इस दृष्टिकोण का उपयोग नहीं कर सकते। यह अधिकांश रोजमर्रा की स्थितियों के लिए बहुत सुरक्षित होगा और अन्य पुस्तकालयों या रूपरेखाओं के साथ असंगत है। लेकिन आपको अपने व्यापार तर्क के सबसे महत्वपूर्ण भागों को ठीक वैसे ही लिखना चाहिए जैसा मैंने दिखाया, ताकि आपके सिस्टम का सही संचालन सुनिश्चित हो सके और भविष्य में सहायता की सुविधा मिल सके।

क्या विषय आपको लगता है या यहां तक ​​कि होलिवरानी भी लगता है? 5 अप्रैल को मॉस्को पायथन कॉन्फ ++ में आएं, हम चर्चा करेंगे! मेरे अलावा, ड्राई-पायथन प्रोजेक्ट के संस्थापक और Django चैनल्स के मुख्य डेवलपर, अर्योम मलीशेव होंगे। वह शुष्क-अजगर और व्यापारिक तर्क के बारे में अधिक बात करेंगे ।