रूबी डीबगिंग में महारत: सामान्य त्रुटियों के लिए त्वरित सुधार

आपका प्रोग्राम पहली बार में कितनी बार वही करता है जो आप चाहते हैं?

कई बार हमारे प्रोग्राम्स हमारी अपेक्षा के अनुसार काम नहीं करते, इसलिए हमें यह पता लगाने में मदद के लिए रूबी डीबगिंग की कला का उपयोग करना पड़ता है कि क्यों।

आप निम्नलिखित त्रुटि संदेश से परिचित हो सकते हैं:

undefined method 'some_method' for nil:NilClass

इसका मतलब है कि एक nil मान हमारे कोड में अपना रास्ता बनाने में कामयाब रहा।

इस लेख में चर्चा की गई तकनीकों का उपयोग करके आप सीखेंगे कि इस मुद्दे और इसी तरह की समस्याओं से कैसे निपटें!

त्रुटियों और स्टैक ट्रेस को समझना

जब आप रूबी इंटरप्रेटर से त्रुटि प्राप्त कर रहे हैं या आपका प्रोग्राम वह नहीं कर रहा जो उसे करना चाहिए तो यह आपकी डीबगिंग टोपी पहनने का समय है।

यदि समस्या यह है कि आपका प्रोग्राम क्रैश हो रहा है, तो त्रुटि संदेश पर ध्यान देना महत्वपूर्ण है, जिसमें आमतौर पर सुराग होते हैं कि क्या गलत हो रहा है।

यहां एक उदाहरण है:

 def method1
  method2
end
def method2
  puts invalid_variable
end
method1 

यह कोड चलाने से आपको निम्न त्रुटि मिलेगी:

 /tmp/stack.rb:6:in 'method2': undefined local variable or method 'invalid_variable' for main:Object (NameError)
from /tmp/stack.rb:2:in 'method1'
from /tmp/stack.rb:9:in '<main>' 

इसे स्टैक ट्रेस के रूप में जाना जाता है।

आइए इसका एक साथ विश्लेषण करें!

हम शीर्ष पर मौजूद लाइन से शुरू करते हैं।

यह वह जगह है जहां वास्तविक त्रुटि हुई, लेकिन इसका मतलब यह नहीं है कि त्रुटि की स्थिति यहीं उत्पन्न हुई।

हालांकि, यह हमारी जांच शुरू करने के लिए एक अच्छी जगह है।

यहाँ सौदा है:

जैसा कि आप देख सकते हैं जब इसे इस तरह तोड़ा जाता है तो त्रुटि उतनी डराने वाली नहीं है।

वैसे, आप अपवादों की सूची यहां पा सकते हैं।

अब:

स्टैक ट्रेस में पहली लाइन के नीचे हर लाइन आपको बताती है कि कोड यहां कैसे पहुंचा।

यह मूल रूप से एक मेथड चेन है, यदि आप नीचे जाते रहें तो आपको अंततः अपने ऐप का मुख्य मेथड मिल जाना चाहिए।

यहां स्टैक ट्रेस से निपटने के लिए एक सामान्य एल्गोरिदम है:

1. स्टैक ट्रेस की शीर्ष लाइन पढ़ें
2. यदि फाइल आपके प्रोजेक्ट का हिस्सा है: दोषपूर्ण फाइल को इंगित लाइन नंबर पर खोलें। यदि नहीं है, तो स्टैक ट्रेस में नीचे जाते रहें जब तक आपको अपनी पहचान की फाइल का पहला संदर्भ न मिल जाए
3. देखें कि क्या कुछ स्पष्ट सामने आता है और इसे ठीक करें (त्रुटि संदेश पर उल्लिखित चीजों को देखें)
4. यदि इससे मदद नहीं मिलती तो आपको अधिक जानकारी ढूंढनी होगी, जैसे प्रभावित वेरिएबल्स के मान।

रूबी डीबगिंग

सबसे बुनियादी (जिसका मतलब खराब नहीं है) डीबगिंग तकनीक जिससे आप शायद परिचित हैं, वह है केवल संदिग्ध वेरिएबल्स के मान डंप करना।

रूबी में आप इसे puts या p का उपयोग करके कर सकते हैं।

p का उपयोग करना puts variable.inspect कहने के बराबर है, और ऑब्जेक्ट्स को देखने के लिए उपयोगी है।

उदाहरण:

 Book = Struct.new(:title)
def find_book(title)
  books = []
  books << Book.new('Eloquent Ruby')
  books.find { |b| b.title == title }
end
book = find_book('Eloquent Ruby')
p book # यह हमारे बुक ऑब्जेक्ट को प्रिंट करेगा
book = find_book('POODR')
p book # यह nil प्रिंट करेगा
book.name # आगे क्या होता है इसका अनुमान लगाएं! 

Pry के साथ गहराई से खुदाई

जब आपके पास जांचने के लिए कई वेरिएबल्स होते हैं, तो हर जगह puts जोड़ना बहुत व्यावहारिक नहीं हो सकता।

उस स्थिति में आपको pry आज़माना चाहिए।

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

pry का उपयोग करना वास्तव में आसान है:

आपको बस binding.pry वहां डालना है जहां आप pry ब्रेकपॉइंट इंस्टॉल करना चाहते हैं।

आपको अपने प्रोजेक्ट में pry की भी आवश्यकता होगी (require 'pry')।

यदि आप इसे केवल अस्थायी रूप से करना चाहते हैं तो आप अपने रूबी स्क्रिप्ट को इस तरह कॉल कर सकते हैं:

 ruby -rpry app.rb 

यह रेल्स ऐप के लिए बहुत मददगार नहीं होगा, इसलिए आप pry को अपने Gemfile में जोड़ना चाह सकते हैं।

मैं जो करना पसंद करता हूं वह है अपने एडिटर पर एक मैक्रो/स्निपेट रखना जिसमें पहले से ही उसी लाइन में require शामिल हो जिस लाइन में ब्रेकपॉइंट है, इसलिए जब मैं इसे हटाता हूं तो मैं दोनों चीजों को हटा दूंगा।

यह वही है जो आप देखेंगे जब आप pry सत्र पर छोड़े जाएंगे:

यदि आप पूरी तरह से pry सत्र से बाहर निकलना चाहते हैं तो आप exit! टाइप कर सकते हैं, यदि आप एक नियमित exit करते हैं तो यह आपके प्रोग्राम को अगले ब्रेकपॉइंट तक चलाता है।

pry की शक्ति यहीं समाप्त नहीं होती। उदाहरण के लिए, आप ls कमांड का उपयोग करके देख सकते हैं कि किसी ऑब्जेक्ट के पास कौन से मेथड्स और इंस्टेंस वेरिएबल्स हैं।

help कमांड चलाना न भूलें ताकि सभी गुडीज की सूची मिल सके!

एक और रूबी डीबगर: Byebug

Byebug pry के प्रतिस्थापन के रूप में या रूबी के लिए gdb-जैसे डीबगर के रूप में कार्य कर सकता है।

यदि आप इसे पूर्व के लिए उपयोग करना चाहते हैं तो आप बस byebug डालें जहां आप चाहते हैं कि आपका कोड रुके binding.pry के बजाय। Byebug का उपयोग करने के नुकसानों में से एक यह है कि यह सिंटैक्स हाइलाइटिंग प्रदान नहीं करता।

आइए देखते हैं कि आप byebug के अंदर ब्रेकपॉइंट्स कैसे सेट कर सकते हैं और अपना कोड डीबग कर सकते हैं!

आमतौर पर आप help कमांड कॉल करेंगे, लेकिन इस मामले में यह जानकारी पर थोड़ा कम है:

तो आपको डॉक्यूमेंटेशन देखना होगा।

आप देख सकते हैं कि break कमांड और एक लाइन नंबर का उपयोग करके आप अपने ब्रेकपॉइंट्स सेट कर सकते हैं।

ब्रेकपॉइंट्स की सूची प्राप्त करने के लिए आप info breakpoint का उपयोग कर सकते हैं।

एक बार आपके ब्रेकपॉइंट्स सेट हो जाने पर, आप निम्न कमांड्स का उपयोग करके प्रोग्राम निष्पादन के माध्यम से आगे बढ़ सकते हैं:

• step (एक निर्देश आगे बढ़ें, मेथड कॉल्स में प्रवेश करें)
• next (एक निर्देश आगे बढ़ें, मेथड्स के अंदर न जाएं)
• continue (अंत या अगले ब्रेकपॉइंट तक चलाएं)

यदि आप बिना किसी कमांड के एंटर टाइप करते हैं तो यह बस अंतिम को दोहराएगा, यह आपके कोड के माध्यम से चलते समय बहुत उपयोगी है।

जब सब विफल हो जाए

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

कभी-कभी आप सुनिश्चित नहीं होते कि समस्या कहां है, जब ऐसा होता है तो आपके पास अभी भी बहुत सारे विकल्प होते हैं।

उदाहरण के लिए, आप समस्या को अलग करने की कोशिश करने के लिए कोड के ब्लॉक्स को कमेंट करना चाह सकते हैं।

यदि समस्या गायब हो जाती है तो आप उस कोड के एक हिस्से को अनकमेंट कर सकते हैं जिसे आपने अभी कमेंट किया था।

यह एक बहुत ही लो-टेक समाधान है, लेकिन यह वही हो सकता है जिसकी आपको आवश्यकता है।

यदि आप यहां तक पहुंच गए हैं और कुछ भी मदद नहीं करता दिख रहा:

बड़े हथियार निकालने का समय आ गया है।

यहां कुछ सिस्टम टूल्स हैं जो आप अक्सर मददगार पाएंगे।

इन टूल्स में से एक है Wireshark, जो आपको नेटवर्क ट्रैफिक का निरीक्षण करने देगा।

यदि आप SSL-एन्क्रिप्टेड ट्रैफिक से निपट रहे हैं तो एक mitm (मैन इन द मिडल) प्रॉक्सी जैसे mitmproxy आपकी मदद कर सकता है।

आप curl को अपने टर्मिनल से HTTP कनेक्शन शुरू करने के लिए भी आज़मा सकते हैं, जो अमान्य सर्वर प्रतिक्रियाओं को डीबग करने में आपकी मदद कर सकता है।

एक और टूल जिससे परिचित होना उपयोगी है वह है strace (केवल लिनक्स)।

Strace आपको आपके ऐप द्वारा किए जा रहे सभी सिस्टम कॉल्स दिखाएगा।

आप -e विकल्प का उपयोग करके विशिष्ट सिस्टम कॉल्स के लिए फ़िल्टर कर सकते हैं। strace का एक अधिक आधुनिक विकल्प sysdig है।

चेतावनी! आप प्रोडक्शन में strace का उपयोग करने से बचना चाह सकते हैं क्योंकि यह टेस्ट के तहत सिस्टम के प्रदर्शन को गंभीर रूप से खराब कर देता है।

अंत में, यदि आप किसी ऐसे मुद्दे से निपट रहे हैं जो लगता है कि किसी बाहरी जेम से आ रहा है, तो एक स्पष्ट कदम जेम के सोर्स कोड का निरीक्षण करना है।

आप अपने कॉन्फ़िगर किए गए एडिटर पर सोर्स कोड खोलने के लिए gem open कमांड का उपयोग कर सकते हैं।

निष्कर्ष

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

कृपया इस पोस्ट को शेयर करें यदि आपको यह पसंद आई ताकि अधिक लोग सीख सकें! 🙂

धन्यवाद।