एरर हैंडलिंग

निर्देश

अलग-अलग तरह की एरर हैंडलिंग और रिसोर्स प्रबंधन लागू कीजिए।

प्रोग्रामिंग में एरर संभालना और एरर होने पर भी रिसोर्स बंद करना एक ज़रूरी बात है।

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

कार्यान्वयन

आप एक छोटा-सा वेब सर्वर बना रहे हैं, जो उससे भी छोटे यूज़र डेटाबेस से डेटा निकालता है। सुनने में आसान लगता है, लेकिन वास्तविक दुनिया में कई चीज़ें गलत हो सकती हैं (और अक्सर होती भी हैं):

• कनेक्शन असुरक्षित हो सकता है: URL की शुरुआत "https://" से होनी चाहिए
• डोमेन नाम अमान्य हो सकता है: इस अभ्यास में यह "example.com" होना चाहिए
• पेज न मिले: केवल "https://example.com/", "https://example.com/users/" और "https://example.com/users/<user_id>" की ही अनुमति है
• user_id धनात्मक पूर्णांक न हो
• इस user_id वाला कोई यूज़र डेटाबेस में मौजूद न हो

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

अच्छी बात है कि Roc आपको अपने Err टैग के अंदर पेलोड (यानी डेटा) रखने देता है। सीधे एरर संदेश रखना लुभावना लगता है (जैसे Err("User #42 was not found")), और कुछ आसान परिस्थितियों में यह ठीक भी हो सकता है, लेकिन इसकी कई सीमाएँ हैं:

• जिस फंक्शन में एरर पकड़ी जाती है, उसके पास इतना संदर्भ नहीं हो सकता कि वह पर्याप्त मददगार एरर संदेश बना सके।
  • उदाहरण के लिए, Str.to_u64 फंक्शन का इस्तेमाल हर तरह के पूर्णांक पढ़ने के लिए किया जा सकता है: दिन, सेकंड, यूज़र ID, और भी बहुत कुछ। अगर एरर संदेश सिर्फ Could not convert string "0.5" to a positive integer कहता है, तो उपयोगकर्ता के पास समस्या हल करने लायक संदर्भ नहीं होगा।
• कई जगहों पर आपके एरर-हैंडलिंग कोड को कुछ एरर दूसरों से अलग तरीके से संभालनी पड़ सकती हैं। लेकिन अगर एरर में सिर्फ स्ट्रिंग पेलोड रखा हो, तो यह जानने के लिए कि कौन-सी समस्या हुई, आपके एरर-हैंडलिंग कोड को उस स्ट्रिंग को पार्स करना पड़ेगा: यह कम कुशल है, और एरर संदेश में ज़रा-सा बदलाव होते ही यह आसानी से टूट सकता है।
• अगर आपकी वेबसाइट बहुभाषी है, तो आपको एरर संदेश का उपयोगकर्ता की भाषा में अनुवाद करना होगा। यह तब कहीं ज़्यादा आसान रहेगा जब एरर का पेलोड अंग्रेज़ी स्ट्रिंग के बजाय मशीन के लिए अनुकूल डेटा हो।

इसलिए इस अभ्यास में आपकी एरर अपने साथ एक अर्थपूर्ण टैग और उसका अपना मददगार पेलोड लेकर चलेंगी। उदाहरण के लिए, अगर यूज़र न मिले, तो एरर कुछ इस तरह दिखेगी: Err(UserNotFound(42)).

ठीक है, चलिए शुरू करते हैं! आपको यह करना है:

1. get_user को ऐसा बनाइए कि वह माँगा गया यूज़र users "डेटाबेस" से लौटाए (वास्तव में यह सिर्फ एक Dict है)। ध्यान रखिए कि अगर यूज़र न मिले, तो फंक्शन Err(KeyNotFound) के बजाय Err(UserNotFound(user_id)) लौटाए।
2. parse_user_id को ऐसा बनाइए कि वह URL के पाथ (जैसे "/users/123") को धनात्मक पूर्णांक यूज़र ID (123) में बदल दे। एरर होने पर Err(InvalidUserId(user_id_str)) लौटाइए।
3. getPage बनाइए:
   • अगर URL "https://example.com/" है, तो Ok("Home page") लौटाइए
   • अगर URL "https://example.com/users/" है, तो Ok("Users page") लौटाइए
   • अगर URL "https://example.com/users/<user_id>" है, तो यूज़र ID पार्स कीजिए, उस ID वाला यूज़र लोड कीजिए, और Ok("<user name>'s page") लौटाइए
   • अगर URL का प्रीफिक्स "https://" नहीं है, तो Err(InsecureConnection(url)) लौटाइए
   • अगर URL का डोमेन नाम "example.com" नहीं है, तो Err(InvalidDomain(url)) लौटाइए
   • अगर पाथ / या /users/ या /users/<user id> नहीं है, तो Err(PageNotFound(path)) लौटाइए
   • अगर यूज़र ID धनात्मक पूर्णांक नहीं है, तो Err(InvalidUserId(user_id_str)) लौटाइए
   • अगर यूज़र मौजूद नहीं है, तो Err(UserNotFound(user_id)) लौटाइए
4. error_essage को ऐसा बनाइए कि वह पिछली एरर को अनुवादित एरर संदेशों में बदल दे। फंक्शन को कम से कम अंग्रेज़ी तो संभालनी ही चाहिए, लेकिन अच्छा होगा कि आप कोई दूसरी भाषा भी संभालने की कोशिश करें। अंग्रेज़ी एरर संदेश ऐसे दिखने चाहिए:

• "Insecure connection (non HTTPS): http://example.com/users/789"
• "Invalid domain name: https://google.com/wrong"
• "Page not found: /oops"
• "User ID is not a positive integer: abc"
• "User #42 was not found"

नोट: जब उपयोगकर्ता HTTPS के बजाय HTTP इस्तेमाल करे, तो उसे एरर संदेश दिखाने के बजाय आपका वेब सर्वर उसके ब्राउज़र को HTTPS पर रीडायरेक्ट कर सकता है, और उपयोगकर्ता को एरर का पता भी नहीं चलेगा। चूँकि Roc में एरर मशीन के लिए अनुकूल होती हैं, इसे लागू करना बहुत आसान होगा।