例外クラスへのコンテキストの追加
最近、 honeybadgerのバージョン3.2を出荷しました。 RubyGem。エラーレポートにコンテキストを簡単に追加できるようにする新機能が含まれています。
tl; dr
ラーテル gemは、#to_honeybadger_contextの定義をサポートするようになりました 任意の例外クラスのメソッド。その例外のインスタンスが発生してHoneybadgerに報告されると、そのコンテキストはエラーレポートに自動的に含まれます：
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に送信できます。 Railsでは、Honeybadger.contextを使用して現在のリクエストのコンテキストを設定できます Ruby gemによって提供されるメソッド：
Honeybadger.context({
user_email: 'user@example.com'
})
現在のリクエスト（またはバックグラウンドワーカーを実行している場合はジョブ）で発生するすべてのエラーには、独自のコンテキストデータがあります。
コンテキストデータは何でもかまいませんが、多くの場合、現在ログインしているユーザーのユーザーIDやメールアドレス、デバッグに役立つ生のPOSTデータやその他の関連ペイロード、バックグラウンドジョブのIDなどが含まれます。
エラーを手動で報告するときにローカルコンテキストを追加することもできます：
Honeybadger.notify(exception, context: {
user_email: 'user@example.com'
})
おもしろい事実：コンテキストは何でもかまいませんが、Honeybadgerにはいくつかの「特別な」コンテキストキーがあります。たとえば、user_emailを含める場合 エラーレポートをキー入力すると、Honeybadgerはエラーごとに影響を受けるユーザーのレポートを作成します。
一部のコンテキストは、要求ではなく、例外自体に固有です。たとえば、faradaygemを使用して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
Honeybadgerはこのエラーを自動的に報告します（そうするように構成されていると仮定します）が、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
これにより、失敗したリクエストを、レスポンスに関する追加情報とともにHoneybadgerに報告できます。
このパターンは、エラーが発生したときに例外固有のコンテキストを追加するために使用します。このパターンが機能している間は、レスキューステートメントとカスタム通知ロジックでコードが乱雑になり、コードに多くのオーバーヘッドが追加されます。良いニュース：もっと良い方法があります！
新機能：例外レベルのコンテキスト
エラーを手動で報告する代わりに、例外クラス自体でコンテキストを定義できるようになりました。 、およびエラーが最終的に報告される場所に関係なく、Honeybadgerは自動的にそれを取得します。
醜いrescueを追加するのではなく、前の例を再検討します ステートメント、Honeybadgerの組み込みレポートが例外を処理できるようにしましょう：
response = conn.get('/does-not-exist') # => Faraday::ResourceNotFound
代わりに、#to_honeybadger_contextを追加しましょう Faraday::ClientErrorへのメソッド 、これは、例外が報告されたときにHoneybadgerがチェックする特別な方法です：
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へのメソッド 、コードを乱雑にすることなく、エラーが発生するたびに応答コンテキストを取得します！
-
Rubyのカスタム例外
Rubyで独自の例外を作成するのは簡単です。次の手順に従ってください： 1。新しいクラスを作成する 例外は、Rubyの他のすべてと同じように、クラスです。新しい種類の例外を作成するには、StandardErrorまたはその子の1つから継承するクラスを作成するだけです。 class MyError < StandardError end raise MyError 慣例により、新しい例外のクラス名は「エラー」で終わります。カスタム例外をモジュール内に配置することもお勧めします。つまり、最終的なエラークラスは次のようになります：ActiveRecord::RecordNotFound
-
なぜクラスを作成するのですか？
前回の記事に続いて、なぜnilを使用するのか、私たちが当たり前と思っている他のことについてこの質問をするのは良い考えだと思いました。 いいね… 醜いコードの巨大なブロブを1つだけ持つのではなく、なぜクラスを使用するのですか？ 基本的なレベルでは、クラスを使用してコードとデータを論理ユニットに編成します。 しかし、それだけではありません。 クラスを使用すると、抽象化を作成できます 。 抽象化とは何ですか？ 毎日、1分ごとに抽象化を使用します。 キーボード 私はこれを入力しています： ケーブル チェリーMXブラックスイッチ すべてをまとめるプラスチックケース 電気信号をコンピュータ