リフレクションを使用していて、メソッドが実装されているかどうかを確認したい場合は、getMethod() メソッドを使用できます。このメソッドは NoSuchMethodException をスローします。
パフォーマンスを最適化するために、この Exception の fillInStackTrace をオーバーロードする方法はありますか? 現在、約 40% の時間がこのメソッドに費やされています。
特定の種類の制御フローを実行する方法として、例外を使用するフレームワークを使用しています。
だから私はあまり侵略的になりたくありません。Throwable を拡張するクラスを作成し、NoSuchMethodException の代わりにこの新しいクラスを使用すると、次のようになります。
NewException is never thrown in body of corresponding trystatement
ありがとう
私の次の2つのポイントは、あなたの質問のタイトルを正確に解決するものではありませんが、役立つと思います...
パフォーマンス測定を確認します。
私はJavaパフォーマンスブックで解決策について読みました。いくつかの例外（スタックトレースが重要ではなく、可能な頻度が高い場合）を除いて、これを独自のアプリケーションに適用しました。あなたがそれを好きになるかどうかはわかりません...;-)
Exceptionクラスの一意のインスタンスを作成し、保存します。そのインスタンスをスローします。
これは、例外に依存する既存のフローを妨害したくない場合に理想的です。
コンパイラが他のメソッドがその例外をスローしないことについて文句を言う場合、それはチェックされた例外を選択したためです。RuntimeExceptionのサブクラスを
使用します（これらはチェックされていないため、コンパイラーはそれらがスローされるかどうかを認識せず、文句を言いません）。
いいえ、直接getMethod()呼び出すため、クラスは署名されており、であるnewため、コードを置き換えることはできません。NoSuchMethodExceptionfillInStackTrace()native
最善の策は、呼び出しをgetMethod()中央の場所にキャッシュすることです。2レベルのマップを作成するだけMap<Class, Map<String, Method>>です。例外をスローせずにクイックルックアップを使用します。