1

場合によっては、かなり適切にデバッグされ、通常はエラーの原因とならないライブラリを使用することがあります。それでも、これらのライブラリは、API の誤用によりエラーを返す可能性があります。このような場合、これらのライブラリの内部ステップがエラーのバックトレース内に表示されます。これは、ライブラリを使用するプログラマーの観点からはゴミであり、エラーの原因を特定することを困難にします。コア Ruby の一部のメソッドでさえ、いくつかの内部ステップをバックトレースに挿入します。たとえば、 を含むバックトレースが表示されるときはいつでも、Enumerable#inject常にそこEnumerable#eachから呼び出されており、これがバックトレースに表示され、煩わしくなります。

  1. 特定のライブラリの内部ステップをバックトレースから削除する良い方法は何ですか? 私は現在、バックトレースを解析し、ファイル名でフィルタリングすることでそれをドンしています。それを行うより良い方法はありますか？

  2. ライブラリを自作する場合、ライブラリを使ったメソッド呼び出しのバックトレースに現れる内部ステップを抑える良い方法はありますか? rescue明らかな方法は、ライブラリの外部から使用されるメソッドごとにandのペアを挿入するraiseことですが、それは正しくないようです。

4

1 に答える 1

1

良い...

  1. フィルタリングするより良い方法は本当にありません。ただし、バックトレースの完全なファイルパスを取得できる場合は、すべての stdlib と gem を除外できるディレクトリでフィルタリングできます。それを超えて、それは価値があるよりも多くのトラブルです。

  2. これにはもっと良い解決策があります。ただし、ライブラリで Ruby によってスローされたすべての例外をキャッチし、これを行った後にそれらを再スローする必要があります (これは、すべての独自の例外に対しても行います)。したがって、すべてのメソッドをこれでラップします。

    begin
  ...
rescue Exception
  e = $!  
  e.set_backtrace(caller(nesting_level))
  raise e
end

    はnesting_level、現在のメソッドが呼び出されたこのライブラリのメソッドの数です。ユーザー コードから直接呼び出された場合は、0 を入力します。ユーザー コードで呼び出された 1 つのメソッドによって呼び出された場合は、1 を入力します。

于 2013-02-18T15:41:30.877 に答える