1

カンマ区切りのテキストファイルからデータを読み取り、エンティティオブジェクトのリストを作成するメソッドがあります。たとえば、顧客です。

たとえば、次のようになります。

Name
Age
Weight

次に、これらのデータオブジェクトを取得して、データベースに保存するビジネスレイヤーに渡します。現在、このファイルのデータは無効である可能性があるため、最適なエラー処理設計を見つけようとしています。たとえば、テキストファイルの[年齢]フィールドに文字データが含まれている場合があります。

今私の質問は、ファイルデータを読み取るメソッドからInvalidAgeExceptionなどの例外をスローする必要がありますか？また、[名前]フィールドに長さの制限があるとすると、長さが最大文字数を超える場合は、NameTooLongExceptionまたは単にInvalidNameExceptionをスローしますか、それともそれを受け入れて、ビジネスレイヤーがそれを取得して例外をスローするまで待ちますか？そこから？

（あなたが私に良いリソースを教えてくれれば、それも良いでしょう）

4

5 に答える 5

3

私は言うだろう-速くそして大声で失敗する。したがって、不整合が発生した瞬間に例外をスローします（ファイル内のすべてのエラーを取得してユーザーに表示する場合を除きます。この場合、収集パラメーターベースの設計と例外ベースの設計が必要です） 。

  • カスタム例外クラスに、可能な限り「意図を明らかにする」名前を付けます。したがって、NameTooLongExceptionはInvalidNameExceptionよりも優れています
  • また、例外はクライアントが問題を修正するのに役立つはずです..（ああ、名前が無効である理由を知るために例外/コードを掘り下げるのではなく、ファイル内の名前を短くする必要があります。）検出と解決を短くしますクライアントのサイクルタイム。
于 2010-03-31T03:30:16.973 に答える
1

データが使用できない場合は、レコードの読み取り時に例外をスローするのがおそらく最善です。たとえば、年齢フィールドの文字データは、ユーザーがアプリケーションの外部でファイルを操作した場合にのみ可能であることがわかっている場合です。これは、オブジェクトをシリアル化しようとし、シリアル化されたデータを台無しにしてから、逆シリアル化しようとした場合に発生することです。

データがアプリケーションの外部で操作されることを意図している場合、またはレコードまたは他のレコードの一部を回復できる場合は、ある種の複合「エラー」コレクションを実装するのが最善です。必ずしも例外をスローする必要はありません。新しいExceptionインスタンスを作成して、それらをコレクションに入れることができます。

つまり、現在の操作を中断し、部分的な結果を返したくない場合にのみ、例外をスローする必要があります。

于 2010-03-31T03:31:48.943 に答える
1

ロジックの設定方法によって異なります。ファイル読み取りロジックがジェネリック（C＃ジェネリックではなく、特定ではないという意味でジェネリック）である場合は、例外を少し上にスローすることをお勧めします。

たとえば、これが設定方法である場合：

// just an example
FileContents ReadFile(string path)
{
   // Don't necessarily throw exceptions related to data validity
}

SomeObject FromFile(string path)
{
   FileContents contents = ReadFile(path);
   // Do throw exceptions related to data validity

   // construct your object
}

それはすべて、検証をどこで行うかに関して意味のあることです。原則として、例外は例外的な状況（その特定のレベルで回復できない状況）でのみスローする必要があります。呼び出しスタックの上位にあるいくつかのメソッドは、その状況で何をすべきかを知っている可能性があります。

また、メソッドの呼び出し元（間接または直接、あなたまたは他の開発者）の礼儀として、多くの異なるタイプの例外をスローする必要がある場合は、例外に共通ベース例外（その他）よりも、必要な数のステートメントSystem.Exceptionでキャッチできます。catch

継承階層の例は次のとおりです。

  • System.Exception
    • DataLoadException
      • NameException
        • NameTooLongException
        • InvalidNameException
      • AgeException
      • ..。

このように、呼び出し元がメソッドが成功したかどうかだけを知りたい場合は、DataLoadExceptionすべてのタイプのスロー可能な例外をキャッチするのではなく、キャッチするだけで済みます。代わりに、発信者が何がうまくいかなかったかを正確に知りたい場合は、それを行うこともできます。

于 2010-03-31T04:00:50.033 に答える
1

メソッドでいくつかのことを行っているようです。

  1. 外部データソース（ファイル）を読み取る
  2. 読み取ったデータからオブジェクトを作成します。
  3. オブジェクトをアプリケーションの別の部分に渡します（さらに処理を実行するため）。

検証を次の場合に限定します。

  1. ここでファイルスローを読み取れない場合（ファイルがない、ファイルの形式が間違っている）。
  2. ここにデータがスローされたためにオブジェクトを作成できない場合（数字以外の文字のために「年齢」を解析できません）。
  3. ビジネスレイヤでビジネスロジック（名前が長すぎるか小さすぎる、重みが大きすぎるか小さすぎる）を検証します。
于 2010-03-31T04:46:26.373 に答える
0

バッチ処理に最適です。つまり、検証とErrorDataクラスを作成します。データクラスには、Linenumber（CSV linenumber）、Message、およびプロパティが適していると思われる場合があります。

ファイルを読み取り、コレクション全体を検証クラスに渡して、ErrorDataクラスのコレクションのエラーを検証および取得します。

正しいデータを処理し、エラーをログに記録するかスローします。ここでは、書き込みデータの処理と、エラーがあることをクライアント（呼び出し元オブジェクト）に通知することの両方を行っています。

誰かがログ/またはエラーメッセージを開いてデータを修正することができます。

于 2010-03-31T04:01:27.033 に答える