Computer >> कंप्यूटर ट्यूटोरियल >  >> प्रोग्रामिंग >> Ruby

त्रुटि रिपोर्टिंग बढ़ाएँ: हनीबैजर में एक्सेप्शन क्लासेस में संदर्भ जोड़ना

हमने हाल ही में honeybadger रूबी जेम का संस्करण 3.2 जारी किया है, जिसमें एक नई सुविधा शामिल है जो आपकी त्रुटि रिपोर्ट में संदर्भ जोड़ना आसान बनाती है।

tl;dr

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

class MyError < StandardError
  attr_reader :custom_attribute
  def initialize(err, custom_attribute)
    @custom_attribute = custom_attribute
    super(err)
  end

  def to_honeybadger_context
    { custom_attribute: custom_attribute }
  end
end

raise MyError.new("Something went wrong", { foo: 'bar' })
# हनीबैजर संदर्भ में शामिल होगा:
# {
#   custom_attribute: {
#     foo: 'bar'
#   }
# }

संदर्भ क्या है?

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

Honeybadger.context({ user_email: 'user@example.com' })

वर्तमान अनुरोध (या जॉब यदि आप बैकग्राउंड वर्कर चला रहे हैं) में होने वाली हर त्रुटि का अपना विशिष्ट संदर्भ डेटा होगा।

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

आप मैन्युअली त्रुटि रिपोर्ट करते समय स्थानीय संदर्भ भी जोड़ सकते हैं:

Honeybadger.notify(exception, context: { user_email: 'user@example.com' })

मजेदार तथ्य: जबकि संदर्भ कुछ भी हो सकता है, हनीबैजर के पास कुछ "विशेष" संदर्भ कुंजियाँ हैं। उदाहरण के लिए, यदि आप अपनी त्रुटि रिपोर्ट के साथ user_email कुंजी शामिल करते हैं, तो हनीबैजर प्रत्येक त्रुटि के लिए प्रभावित उपयोगकर्ताओं की एक रिपोर्ट बनाएगा।

एक्सेप्शन से संदर्भ जोड़ना

कुछ संदर्भ एक अनुरोध के बजाय एक एक्सेप्शन के लिए विशिष्ट होते हैं। उदाहरण के लिए, मान लें कि हम फैराडे जेम का उपयोग करके एक HTTP अनुरोध कर रहे हैं:

require 'faraday'
conn = Faraday.new(:url => 'https://example.com') do |faraday|
  faraday.response :raise_error # अनुरोध सफल न होने पर त्रुटि उठाता है
  faraday.adapter Faraday.default_adapter
end
response = conn.get('/does-not-exist') # => Faraday::ResourceNotFound

उपरोक्त कोड निम्नलिखित अपवाद उठाता है:

Faraday::ResourceNotFound: the server responded with status 404

हनीबैजर स्वचालित रूप से इस त्रुटि की रिपोर्ट करेगा (यह मानते हुए कि यह ऐसा करने के लिए कॉन्फ़िगर किया गया है), लेकिन इसमें response ऑब्जेक्ट के बारे में कोई जानकारी नहीं होगी। यह जानकारी होना अच्छा होगा, विशेष रूप से कम स्पष्ट सर्वर त्रुटियों के लिए, जैसे 500 प्रतिक्रिया।

GitHub पर Faraday::ResourceNotFound की परिभाषा को देखते हुए, हम देखते हैं कि यह वास्तव में ClientError का एक प्रकार है, और ClientError एक विशेषता को परिभाषित करता है जो प्रत्येक इंस्टेंस पर प्रतिक्रिया ऑब्जेक्ट को संग्रहीत करता है।

इस जानकारी का उपयोग करके, हम Faraday::ClientError के सभी इंस्टेंस को रेस्क्यू कर सकते हैं और प्रतिक्रिया के बारे में कुछ डेटा संदर्भ में जोड़ने के लिए Honeybadger.notify का उपयोग कर सकते हैं:

begin
  response = conn.get('/does-not-exist')
rescue Faraday::ClientError => err
  Honeybadger.notify(err, context: {
    response_status: err.response.status,
    response_headers: err.response.headers
  })
  # अतिरिक्त त्रुटि संचालन...
end

यह हमें विफल अनुरोधों को हनीबैजर को रिपोर्ट करने की अनुमति देता है साथ ही प्रतिक्रिया के बारे में कुछ अतिरिक्त जानकारी के साथ।

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

नई सुविधा: एक्सेप्शन-स्तर का संदर्भ

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

पिछले उदाहरण पर फिर से विचार करते हुए, एक भद्दा rescue स्टेटमेंट जोड़ने के बजाय, आइए हनीबैजर के बिल्ट-इन रिपोर्टिंग को अपवाद को संभालने दें:

response = conn.get('/does-not-exist') # => Faraday::ResourceNotFound

इसके बजाय, आइए Faraday::ClientError में #to_honeybadger_context मेथड जोड़ें, जो एक विशेष मेथड है जिसे हनीबैजर किसी भी अपवाद के रिपोर्ट होने पर जांचता है:

Faraday::ClientError.class_eval do
  def to_honeybadger_context
    { response_status: err.response.status, response_headers: err.response.headers }
  end
end

Faraday::ClientError में #to_honeybadger_context मेथड जोड़कर, हमें उस त्रुटि के होने पर प्रतिक्रिया संदर्भ मिलेगा, बिना हमारे कोड को अव्यवस्थित किए!

  1. Pry में अपवाद हैंडलिंग में महारत हासिल करें: Rails कंसोल के लिए उन्नत तकनीकें Pry में अपवाद हैंडलिंग में महारत हासिल करें: Rails कंसोल के लिए उन्नत तकनीकें

    यदि आप मेरी तरह हैं, तो आप Rails कंसोल का बहुत उपयोग करते हैं। और अब तक मुझे लगता है कि हर कोई सहमत है कि Pry, Rails कंसोल के लिए अब तक की सबसे अच्छी चीज है... ठीक है, कभी भी। Pry में अंतर्निहित कुछ वास्तव में कूल फीचर्स हैं जो अपवादों के साथ काम करना सादे पुराने IRB की तुलना में बहुत आसान बनाते हैं

  1. Ruby में कस्टम अपवाद में महारत हासिल करें: एक चरण-दर-चरण गाइड Ruby में कस्टम अपवाद में महारत हासिल करें: एक चरण-दर-चरण गाइड

    Ruby में अपने स्वयं के अपवाद बनाना आसान है। बस इन चरणों का पालन करें: 1. एक नई क्लास बनाएं अपवाद क्लास हैं, Ruby में बाकी सब की तरह! एक नए प्रकार का अपवाद बनाने के लिए, बस एक क्लास बनाएं जो StandardError, या उसके बच्चों में से एक से इनहेरिट करती है। class MyError < StandardError end raise MyError

  1. प्रोग्रामिंग में क्लासेस का महत्व: कोड व्यवस्थित करना और अमूर्तता बढ़ाना प्रोग्रामिंग में क्लासेस का महत्व: कोड व्यवस्थित करना और अमूर्तता बढ़ाना

    मेरे पिछले लेख के बाद, हम nil का उपयोग क्यों करते हैं, मुझे लगा कि अन्य चीजों के लिए भी यह सवाल पूछना एक अच्छा विचार होगा जिन्हें हम स्वाभाविक मान लेते हैं। जैसे… हम केवल एक विशाल बदसूरत कोड के ब्लॉब के बजाय क्लासेस का उपयोग क्यों करते हैं? एक मौलिक स्तर पर, हम कोड और डेटा को तार्किक इकाइयों में व्य