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

अपवाद वर्गों में संदर्भ जोड़ना

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

tl;dr

हनीबैगर मणि अब #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' })
# Honeybadger context will include:
# {
#   custom_attribute: {
#     foo: 'bar'
#   }
# }

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

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

Honeybadger.context({
  user_email: '[email protected]'
})

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

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

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

Honeybadger.notify(exception, context: {
  user_email: '[email protected]'
})

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

अपवादों से प्रसंग जोड़ना

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

require 'faraday'

conn = Faraday.new(:url => 'https://example.com') do |faraday|
  faraday.response :raise_error # Raises an error if the request isn't successful
  faraday.adapter  Faraday.default_adapter
end

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

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

Faraday::ResourceNotFound: the server responded with status 404

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

Faraday::ResourceNotFound . की परिभाषा को देखते हुए GitHub पर, हम देखते हैं कि यह वास्तव में एक प्रकार का 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
  })
  # Additional error handling...
end

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

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

नई सुविधा:अपवाद-स्तर प्रसंग

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

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

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

इसके बजाय, आइए #to_honeybadger_context जोड़ें Faraday::ClientError के लिए विधि , जो एक विशेष तरीका है जब हनीबैगर किसी अपवाद की सूचना मिलने पर जाँच करता है:

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

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


  1. Pry . में अपवादों के साथ कार्य करना

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

  1. रूबी में कस्टम अपवाद

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

  1. हम कक्षाएं क्यों बनाते हैं?

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