私は Java (主に数学、UI、グラフィックス) の経験が豊富org.w3c.domですが、JDBC のような API や、チェックされた実行時例外の処理に大きく依存している API を真剣に扱ったことはありません。したがって、これらの種類の API で動作する一連のメソッドを作成する場合、例外をすぐにキャッチするか、メソッドのシグネチャに追加して例外をフレームの上位レベルに伝播するか、例外をどう処理するかをどのように決定すればよいでしょうか。スタック、それらはすべてどこで処理されますか? これらのチェック済み例外でやりたいことは、エラーが発生するたびにエラーでアプリケーションを終了することだけのようです。
1534 次
5 に答える
2
例外を処理する適切な場所は、具体的な状況に完全に依存します。アプリケーションを終了したいだけの場合は、例外をキャッチせずに throws 句で宣言します。
ただし、サーバー プログラムの場合、これは適切な戦略ではありません。たとえば、短いネットワークの問題が原因で DB に到達できないときにサーバーがクラッシュするのは望ましくありません。
于 2014-10-18T08:31:08.730 に答える
1
これは難しい質問です。B.Meyer の本の 5 つのモジュール性基準の 1 つは保護です。この基準は、エラーがクラスまたはモジュールで発生した場合、ホール システムに広がってはならないことを示しています。したがって、エラーはシステムの他のコンポーネントから分離する必要があります。
したがって、システムの低レベルで例外をキャッチする必要があると思います。
于 2014-10-18T08:35:09.600 に答える
1
例外が、ネットワークの問題、xml の不適切な形式などの外部ソースによって引き起こされた問題を示している場合 (例外の種類によって異なります)。次に、それについて何かできる場所でそのような例外をキャッチする必要があります-それがGUIアプリケーションの場合は、ユーザーにエラーダイアログを表示できる場所でキャッチし、決定を下す必要があります. それがサーバー上にある場合は、エラーをログに記録し、クライアントに返します。例外がプログラミングのバグによるものである場合は、GUI アプリケーションでログに記録するか、ユーザーが電子メールでユーザーに送信できるようにします。コマンドラインツールの場合、アプリケーションを例外で終了させ、そのすべてのデータを出力にスローします。それがGUIアプリケーションの場合は、むしろそれをキャッチして、問題があることをユーザーに知らせて回復しようとします。
このような例外を電子メールに自動的に送信するグローバル例外ハンドラーをプログラムに追加することもできます。
于 2014-10-18T08:45:33.617 に答える