APIの複数の方法で例外処理を集中管理する方法

JBC：

これは、単純なJava 8+の質問、使用なしフレームワークです。

私たちは、他の活動の中でプレゼンテーション層を扱う上位層のためのAPIを生産しています。我々は持っていると、彼らは私たちが投げるいくつかの特定の例外を受け取るために満足しているので、インタフェースは、呼び出し元と合意しました。

私たちは自分でものを行うと例外を投げるか、我々は合意された例外をスロー他のAPIを呼び出すことができることができるように、同時に、我々はまた、同じ契約の下で他のAPIを使用しています。現在、我々は起動されるAPIによってスローされる例外を除いて、何もしません。

事は私達が、私達の例外と我々が起動され、それらが提供する例外の両方をキャプチャする必要があるので、我々は、例外がスローされている間の中間の活動に対処するために、このインフラストラクチャに位置し最高です、です。基本的になど、システムのコントロールを上げ、問題を報告し、それが今であるとして、トップ層が保持しますので、その後、元の例外を再スローします。

私たちは、APIのエントリポイントクラスで約300のメソッドがあります。

public void method1 (arguments for method 1) {
...
}

...

public void method300 (arguments for method 300) {
...
}

私ははっきりと私は例外管理に取るべき行動を集中管理するためのメソッドを作成することができることを理解し、のようなもの：

public void myExceptionHandler (Exception e) {
    if (e instanceOf X) {
    } else if ...
    ...
    throw particularExceptionAccordingTheCase 
}

しかし、私はまた、これらの300個の方法を変更しないと思います。

実際にそれらのそれぞれでのtry-catchを追加することなく、myExceptionHandlerに例外を送信するために、これらの300点の方法でのtry-catchを注入する方法任意のアイデア？

すべてのコメントやアイデアに感謝しています！

----------- mprev0提案した後-------------------------------

私はこのアプローチを試してみました。それは本当になどの例外をキャッチし、私は例外を再トロウすることはできません：私はそれをキャッチすることを余儀なくんだけど、これは最上位層への例外バックを再送信の要求に反します。私はエラーを投げることができますが、私はラインでコンパイラエラーが新しいFileNotFoundExceptionを（）を投げました。

public class myExceptionHandler implements Thread.UncaughtExceptionHandler {

    @Override
    public void uncaughtException(Thread t, Throwable e) {
        System.out.println("gotcha!");
        if (e instanceof java.lang.Error) {
            System.out.println("AAT-CORE: Fatal Error");
            throw new java.lang.Error(e.getCause());

        } else if (e instanceof java.lang.Exception) {
            System.out.println("AAT-CORE: Exception Error");
            throw new FileNotFoundException();
        }
    }

}

何か案は？

------------いくつかのより多くの掘削後、Decoratorパターンで固定-------

私は、メソッドのシグネチャを変更することはできませんし、私はのjava.lang.Exceptionを再スローする必要があるとして、前のクラスの実装では、ない作業を行います。

デコレータを使用してインタフェースを扱うトリックができます。まとめると：

トップ層のクラス：

public class TopLayer {
    public static void main (String[] args) {
        MiddleLayer m = new MiddleLayer();
        m.method1();
    }
}

最下層クラスは、特定のAPIやいくつかの実装を含む、唯一興味深いのは、それがjava.lang.Exceptionsはこの仕事をするための最上層を期待して、制御されていない含まれていることです。しかし、私たちは途中で作業していると我々はこの仕事を行います。

public class MiddleLayer extends BottomLayer {

    public MiddleLayer () {
        final UncaughtExceptionHandler subclass = Thread.currentThread().getUncaughtExceptionHandler();
        Thread.currentThread().setUncaughtExceptionHandler(new UncaughtExceptionHandler() {
            @Override
            public void uncaughtException(Thread thread, Throwable ex) {

                System.out.println("gotcha2!");
                // carry on with prior flow
                subclass.uncaughtException(thread, ex);
            }
        });

    }

}

このように、私はのSystem.outを得ることができるとのjava.lang.Exceptionは、トップレイヤーに伝播されます。

デコレーターのインスピレーションはここから来た：再スローたuncaughtExceptionHandler例外それをログに記録した後、

追加のコメントを歓迎します！

JBC：

あなたが質問のアップデートで見ることができるように、最終的な解決策は、この上にjava.lang.Thread.UncaughtExceptionHandlerとを、実装のmprev0アプローチを持つことに装飾パターンを追加し、片側に、2つの異なるアプローチを組み合わせたものです実行時例外を再スローすることができます。

私は、質問を閉じて、最も完全なレスポンスとしてこれを持っていますので、追加のアプローチは、これまでありませんでした。

たuncaughtExceptionHandlerの詳細については、Javaのマニュアルに記載されていますが、いつものように、ここで例に短く、することができます扱う高度な例外のThread.UncaughtExceptionHandler例

Decoratorパターンの使用方法の詳細については、ここで見つけることができます：JavaでのDecoratorデザインパターンデザインパターン- Decoratorパターン

そして、ここでの例外を操作するために使用する方法：再スローたuncaughtExceptionHandler例外それをログに記録した後、

APIの複数の方法で例外処理を集中管理する方法

おすすめ