1

ロギング以外に、例外処理を構成するものは何ですか? 処理できる例外のみをキャッチすると人々が言うように、私は尋ねます。

たとえば、Active Directory とやり取りするためのツールを作成しました。ドメインコントローラーで実行します。私は AD について詳しい知識を持っているので、別の例外的なケースを処理して (たとえば、別のドメイン名を要求するプロンプトを表示することができます)、そこから先に進みます。しかし、本番サーバーのドメインに重大な問題が発生した場合、これは例外的なことではないでしょうか?

したがって、この場合、環境の問題は例外的なはずですが (本番環境や AD などを考えると)、これは私が処理できるものです。例外の処理は、プログラムの視聴者に依存すると思います (同意します)?

とにかく、主な質問：例外を「処理」できるかどうかを推測するには、ログに記録してユーザーに別の選択肢を提示する以外に、どのようなハンドルが必要かを知る必要があります（その場合、ファイルが存在する場合などを使用して例外を回避します）。

上記のケース (AD) の場合、コードを次のように構成しました。

if (adIsAvailable)
  // do whatever here

else
  raise exception and ask for action

これは gui でキャッチされます

その設計の有効性について何か考えはありますか?

4

2 に答える 2

1

素晴らしい質問です。特定のタイプの例外のみを処理し、本当に重要な例外をスタックの上に伝播して無視できることを忘れないでください。

もちろん、あなたが言ったように、例外処理の使用法の1つのタイプはユーザーとの対話です。最善の方法は、実際のタスクを実行して依存するのではなく、違反した場合（ファイルが存在しない場合）に例外をスローするという前提条件を確認することです通知の例外メカニズムについて。

例外処理のもう 1 つの用途は、再試行です。たとえば、クエリを DB に送信していて、TimeOutException を受け取ったり、接続が一時的に利用できないことを示す別のエラーを受け取ったりします。この場合、少し待ってからもう一度試してください。そして、たとえば 3 回後に Db に到達できなかった場合にのみ、例外を上位層に伝播します。

例外を処理する別の方法は、データを例外に追加するか、そのタイプを変更することです。TimeOutException をキャッチしたいが、実行しようとした SQL などを含む MyApplicationException をスローしたい場合があります (元の例外は内部例外です)。

さらに、セキュリティ上の理由から、スタック トレースなどの例外からデータを削除することもできます (アプリケーションの内部動作を悪意のあるユーザーに公開することは賢明ではありません)。

ところで、あなたのケースでは、ユーザーにスタック トレースとあいまいなメッセージを提示する代わりに、問題の性質を明確に示すユーザー フレンドリーなメッセージをフォーマットすることをお勧めします。これは、例外処理中に実行できる変換の別の例です。

少し前に、DML 操作で表スペースのスペース不足から発生した例外がアプリからスローされました。ユーザーは、エラー コードで恐ろしい例外を受け取りました。私がしたことは、コマンドの呼び出しからスローされた例外を検査するハンドラーを追加し、このエラー コードの特別な処理を追加したことです。ユーザーに問題が何であるかを正確に伝えます。

于 2012-07-25T21:25:38.157 に答える
1

ここでは、いくつかの異なる問題が組み合わされています。

  1. 基になるコードによってスローされる例外を処理する方法 (およびいつ処理するかを決定する)
  2. 自分で例外をスローする場合
  3. 製品コードが「例外的な」状況を開発とは異なる方法で扱うべきかどうか。コード。

ポイント（1）について：

これは少し面倒で判断が難しい場合があります。同じ言語内であっても、異なる API では異なる方法で例外を使用する場合があります。

たとえば、C# では、入力が解析に失敗する可能性があると予想される場合は、a をキャッチするint.TryParse()よりも使用することを好み、そのケースを処理するコードを記述したいと考えています。int.Parse()FormatException

不正な入力を処理したくない場合は、 を使用int.Parse()して、例外を伝播させます。

残念ながら状況次第です。

ポイント（2）について：

例外は基本的に「あきらめる」ことを意味します。彼らは何かがうまくいかなかったことを意味しますが、あなたはそれを自分で処理するつもりはありません。

ポイント（3）について：

これはほとんどの場合、悪い考えだと思います。

余談:

Vitality's answer の一部に同意しません。

最善の方法は、実際のタスクを実行して通知の例外メカニズムに依存するのではなく、違反した場合 (ファイルが存在しない場合) に例外がスローされるという前提条件を確認することです。

次のようなコードを書く場合:

if (file_exists(x))
{ /* do something */ }
else
{ /* whatever */ }

次に、競合状態に自分自身を開きます。チェックの間にファイルが削除された可能性があるfile_exists()ため、コードはとにかく例外をスローします。

または、セクションに入った直後にファイルが作成された可能性がありますelse。

このような場合は、やろうとしていることを実行し、何か問題が発生した場合は例外を処理する方がよいと思います。

于 2012-07-25T21:41:53.493 に答える