2

個人的には（私が正しいか何かを意味するわけではありません）、メソッドにtry-catchステートメントを含めると、リーダーの内部構造が「オーバーロード」されるように見えます。DBを操作するときは、SQLExceptions、ConnectionExceptionsなどを含める必要があります。1つのオブジェクトにすべての例外の責任を負わせる方法はありますか？

私はそのようなことを考えました：

enum TaskEnum {
    doSmth1, doSmth2, doSmth3, doSmth4
}

class OuterClass {

    doWhatever(TaskEnum task, String… args) {
        try {
        switch(task) {
                case (doSmth1): InnerClassInstance.execute1(args); break;
                case (doSmth2): InnerClassInstance.execute2(args);break;
                case (doSmth3): InnerClassInstance.execute3(args);break;
                case (doSmth4): InnerClassInstance.execute4(args);break;

        } catch(Exception e) {
                 e.printStack()}
         }
     }
}

class InnerClass {    
    execute1(String args) throws Exception() {bla-bla-bla};
    execute2(String args)throws Exception() { bla-bla-bla };
    execute3(String args)throws Exception() { bla-bla-bla };
    execute4(String args)throws Exception() { bla-bla-bla };
}

このようにして、外部クラスは、彼のすべての内部クラスメソッドによってスローされた例外を処理します。もちろん、私の解決策が良いものだと考えられれば、私はこの質問をしません。これは単なる例であり、アイデアを理解するためのものです。

これについてのあなたの考えを共有してください。

4

4 に答える 4

5

例外メカニズムの優れた点は、例外が発生した場所で処理する必要がなく、共通の場所で、考えられる多くの障害の処理をグループ化することです。そうです、都合の良い時まで例外の処理を確実に延期してください。主な選択肢は 2 つあります。

  1. 現在の作業単位を中止する必要がある障害: トランザクション スコープ全体を包含するレベルでそれらすべてを処理し、均一に処理します (通常は、ログ エントリとアップストリーム クライアントへのエラー メッセージ)。

  2. 作業単位内の代替プログラム フローのみを意味する例外: これらは、具体的かつ早期に処理する必要があるため、チェック済み例外の適切な候補です。これらをエラー レベルでログに記録しないでください (コンテキストに応じて、警告または単なる情報になる可能性があります)。

残念ながら、Java のチェック済み例外により、最初のオプションの実装が難しくなります。これは、途中のすべてのメソッドが、スローされる可能性があるすべてのチェック済み例外を宣言する必要があるためです。また、いくつかの一般的な落とし穴もあります。Eclipse やその他のツールでは、コードをボイラープレートの try-catch で囲みますが、代わりに例外を上方に伝播させる必要があります。発生したチェック済み例外を宣言しないメソッドを実装している場合、特に困難な状況が発生し、処理が早すぎます。そのような場合、チェックされた例外をラップRuntimeExceptionして再スローする必要があります。これは非常に明白ではなく、多くのバグ、または少なくとも重複したエラー ログ エントリの原因となります。

于 2013-02-18T21:08:41.797 に答える
1

あなたが言ったように、一般的に使用される2つのオプションがあります。発生した例外を処理するか、すべての例外を処理する最上位クラスに到達するまで、下位レベルのメソッド自体がエラーをスローするようにします。個人的には、例外はスローされた場所で処理する必要があり、可能な限り具体的にする必要があると感じています。私は 2 番目のオプションのファンではありません。トップ レベルのクラスに責任が重くなりすぎるからです。ただし、それは実際にはあなたの好みであり、もちろん、便利で理にかなっている場合にのみ例外を処理する必要があります。

于 2013-02-18T21:07:30.497 に答える
1

私はまだあなたが何をしようとしているのか理解できません。スタック トレースを出力するだけの catch ブロックは、私見では役に立たない以上のものです。そして、そのような値をオンにするためだけにタスク列挙型を提供することは、私には意味がありません。その道をたどりたい場合は、Java が提供するものを使用してください。

enum TaskEnum {
    doSmth1() {
        public void execute(String... args) {
            // blablabla
        }
    },
    doSmth2() {
        public void execute(String... args) {
            // blablabla
        }
    };

    public abstract void execute(String... args);
};

class OuterClass {

    public void doWhatever(TaskEnum task, String... args) {
        try {
            task.execute(args);
        } catch (Exception e) {
            e.printStackTrace();
            // and do something useful!
        }
    }

}

ただし、例外をまったくキャッチしないか、必要に応じて別の例外クラスにラップする方が良いでしょう (つまり、スローされる例外にスーパークラスが制限を課す場合)。

于 2013-02-18T21:22:02.647 に答える
0

throwsクラス レベルでは使用できず、メソッド レベルでのみ使用できます。

あなたがすることができます：

public void method() throws IOException {

}
于 2013-02-18T21:06:01.947 に答える