0

オブジェクト指向プログラミングでは、複数のエラーの処理に関する概念パターン、アイデアはありますか?

たとえば、いくつかのチェックを実行し、見つかったエラーごとにエラー メッセージを返すメソッドがあります。

[「名前が短すぎます」、「名前に無効な Unicode シーケンスが含まれています」、「名前が長すぎます」]

さて、例外の配列を使用する必要がありますか (スローされた例外ではありません)。

またはこのようなものが良いです：

class MyExceptionList extends Exception{
  public Void addException(Exception e){}
  public Array getExceptions(){}
}

この議論の背後にある理論は高く評価されます!

(これは特定のプログラミング言語に関する要求ではなく、純粋に理論的なものです)

前もって感謝します

4

4 に答える 4

1

私の長年の経験から、エラーを処理するには、すべてのレベルでエラーをログに記録し、成功/失敗を示す関数から true/false を返すことによって行うのが最善です。

ロギングは実装に依存します。ファイル、メモリ、およびエラーの正確な場所を特定できる限り、メッセージ、一意の番号などをログに記録できます。

多くの操作を実行する場合、それぞれが前任者の成功に依存する場合に、例外を使用することがあります。ifこれにより、エラー チェック用の sがなく、コードがよりクリーンになります。それにもかかわらず、これは気にする主なことではありません。主なことは、エラーをログに記録し、成功/失敗を返すことです。通常の方法を続行するかどうかを決定できるように、成功/失敗が必要です (読み取りサイズがメモリをオーバーランする可能性があるため、意図した操作を実行しないなど)。

さらに 2 つの重要な注意事項:

1) メッセージをレポート (ログ) するための非常に簡単な API を構築する必要があります。

2) ログまたはレポートが簡単に表示され、発生した問題について通知されることが不可欠です。そうしないと、エラー報告メカニズムをまったく使用していないことに気付くかもしれません。

これは私にとって非常に重要なテーマであり、ソフトウェア エンジニアリングにおける最も重要な問題の 1 つだと考えています。詳細については、私のウェブサイトをご覧ください。

于 2012-12-15T17:35:04.407 に答える
1

残念ながら、多くの言語とフレームワーク (C++、Java、および .net を含む) は、例外オブジェクトの型を必要とする例外処理メカニズムを使用して、次のような多くの質問に同時に答えます。

  1. どうしたの
  2. スタックの巻き戻しを超えて実行する必要があるアクション
  3. 少なくとも例外によって示された問題に関して、どの時点でシステムが「既知の」状態にあると見なされるべきか。

残念ながら、これらの質問への回答にはある程度の関連性がありますが、実際には 100% の相関関係にはほど遠いものです。残念ながら、例外の型がこれらすべての質問に答えるのに十分であるという仮定は、多くの状況に賢明に対処することを困難にします。

スローされる可能性のあるすべての例外を制御できる場合は、例外処理オブジェクトに仮想IsResolvedプロパティまたはメソッドと、例外が必要な場合にShouldCatchAs<T>を返すプロパティまたはメソッドが含まれる例外処理パラダイムを使用すると役立つ場合があります。Tとして扱われますT。このようなパラダイムは、以前の例外からスタックをアンワインドしているときに例外が発生する状況をスムーズに処理できます (既存の例外と新しい例外は複合例外オブジェクトにラップされ、そのShouldCatchAsプロパティは元の例外のプロパティを結合し、プロパティは、元の例外の両方のプロパティが同様の場合にIsResolvedのみ返されます)。trueIsResolved

パラダイムに適合しないすべての例外をキャッチしてラップしない限り、そのような動作を既存のフレームワークに統合する方法はわかりませんが、おそらく将来のフレームワークはそのようなことを容易にすることができます.

于 2012-12-16T02:23:08.453 に答える
0

その場合、s を投げてはいけませんException。

AnExceptionは例外的な場合を意味します。検証メソッドで見つかったエラーは「例外的」とは見なされません。検証エラーが発生することは明らかです。

例外的な状況は、データベースへの接続に失敗した場合などです。

すべての検証エラーを配列に記録し、それをフォーマットして、好きなように表示する必要があります。

于 2012-12-15T17:06:17.757 に答える
0

例外は検証を目的としたものではなく、実行中に予想とは異なる何かが発生したときに作成されることを目的としています。これが、一度に多くの例外を作成できない理由ですが、他の例外が発生したために例外が発生する可能性があります。これが、case という名前の親例外を持つことができる理由です。

于 2012-12-15T17:07:08.787 に答える