例外を投げる通知を置き換える

Martin Fowlerの記事「 Replace Throw With Notification 」の翻訳に注目してください。 .NETに適合した例。



データを検証する場合、通常、検証エラーを報告するために例外を使用しないでください。 ここでは、「通知」パターンを使用してこのようなコードをリファクタリングする方法を説明します。







最近、着信JSONメッセージの基本的な検証を行うコードを見ました。 こんな感じで......

public void heck() { if (Date == null) throw new ArgumentNullException("  "); DateTime parsedDate; try { parsedDate = DateTime.Parse(Date); } catch (FormatException e) { throw new ArgumentException("    ", e); } if (parsedDate < DateTime.Now) throw new ArgumentException("     "); if (NumberOfSeats == null) throw new ArgumentException("   "); if (NumberOfSeats < 1) throw new ArgumentException("     "); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、検証を実装するための一般的なアプローチです。 一部のデータに対して一連のチェックが開始されます（上記の例では、2つのパラメーターが検証されます）。 チェックに失敗すると、エラーメッセージとともに例外がスローされます。



このアプローチにはいくつかの欠点があります。 まず、この方法で例外を使用しないでください。 例外は、何かが予想される動作コードを超えたことを示します。 ただし、入力パラメーターのチェックを行う場合、これはエラーメッセージを予期しているためです。エラーが予期される動作である場合、例外を使用しないでください。

エラーが予期される動作である場合、例外を使用しないでください

このコードの2番目の問題は、最初のエラーが検出されるとクラッシュすることですが、通常は、最初のエラーだけでなく、着信データですべてのエラーを通知する方が適切です。 この場合、クライアントはすべてのエラーをユーザーに表示することを選択できるため、ユーザーは1つの方法でエラーを修正できます。 これは、コンピューターで海戦をしているという印象をユーザーに与えるよりも優れています。



上記のような場合は、「通知」パターンを使用することをお勧めします。 通知は、エラーを収集するオブジェクトです。 各検証エラーは、通知にエラーを追加します。 検証オブジェクトは、情報を受信するために統合できる通知を返します。 簡単な使用例は次のとおりです。

 private void ValidateNumberOfSeats(Notification note) { if (numberOfSeats < 1) note.addError("     "); //  ,    }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、Notification.hasErrors（）メソッドを呼び出してエラーに応答するだけです。 他の通知方法では、エラーの詳細が提供される場合があります。



if（numberOfSeats <1）throw ArgumentException（「場所の数は正数でなければなりません」）;

  if (numberOfSeats < 1) note.addError("     "); return note;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このリファクタリングを使用する場合

私はあなたのコードで例外の使用を避けることを支持していないことに注意すべきです。 例外は、予期しない状況を処理し、ロジックのメインフローから分離するための非常に便利な手法です。 このリファクタリングは、例外としての出力信号が例外的な状況ではないため、メインプログラムロジックで処理する必要がある場合に意味があります。 上記のコードは、このような状況の一般的な例です。



例外を使用するための適切なルールは、「Pragmatic Programmers」という本にあります。

プログラムの通常のフローの一部として例外を使用することはめったにないと考えています。例外は、予期しない状況のために予約する必要があります。 未処理の例外によってプログラムが終了し、「すべての例外ハンドラーを削除してもこのコードは機能しますか？」と自問します。答えが「いいえ」の場合、例外は通常のプログラムフローの一部として使用されています。



-デイブ・トーマスとアンディ・ハント

これから導き出される重要な結論は、特定のタスクに例外を適用するかどうかは、コンテキストに依存します。 存在しないファイルの読み取りは、例外である場合とそうでない場合があります。 たとえば、Unixの/ etc / hostsなど、よく知られた方法でファイルを読み取ろうとすると、ファイルがここにあると想定できるため、例外をスローすることは理にかなっています。 一方、コマンドラインを介してユーザーが提供したパスに沿ってファイルを読み取る場合、おそらくここにファイルがないことを予期し、本質的に非排他的エラーと対話するために別のメカニズムを使用する必要があります。



検証エラーの例外の使用が適切な場合があります。 これらは、処理中に検証に合格したデータが存在する状況ですが、保護のために検証を再度実行する必要があります

無効なデータがすり抜けることを可能にするソフトウェアエラーから自分自身を守る。



この記事では、生の入力検証のコンテキストで、例外を通知に置き換えることについて説明します。 また、この手法は、例外をスローするよりも通知のほうが適している他の状況でも役立ちますが、最も一般的であるため、検証ケースに焦点を合わせます。

出発点

これまでのところ、ビジネスロジックについては触れていません。コードの一般的な形式に集中することが重要だったからです。 しかし、さらに議論するために、ビジネスロジックに関する情報を取得する必要があります。 この場合、一部のコードは、劇場の座席が予約されているJSONメッセージを受信します。 コードは、JSON.NETライブラリを使用してJSONから取得したBookingRequestクラスにあります。

  JsonConvert.DeserializeObject<BookingRequest>(json);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

BookingRequestクラスには、ここで検証する2つの要素のみが含まれています。パフォーマンスの日付とリクエストされた座席数です。

  class BookingRequest { public int? NumberOfSeats { get; set; } public string Date { get; set; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

検証はすでに上に示されています。

 public void heck() { if (Date == null) throw new ArgumentNullException("  "); DateTime parsedDate; try { parsedDate = DateTime.Parse(Date); } catch (FormatException e) { throw new ArgumentException("    ", e); } if (parsedDate < DateTime.Now) throw new ArgumentException("     "); if (NumberOfSeats == null) throw new ArgumentException("   "); if (NumberOfSeats < 1) throw new ArgumentException("     "); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

通知を作成

通知を使用するには、Notificationオブジェクトを作成する必要があります。 通知は非常に単純な場合があり、場合によっては単なるリストです。

  var notification = new List<string>(); if (NumberOfSeats < 5) notification.add("      5"); //   // … if (notification.Any()) //  
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

上記の実装ではパターンを使用することもできますが、もう少し実行して、代わりに単純なクラスを作成することをお勧めします。

 public class Notification { private List<String> errors = new List<string>(); public void AddError(string message) { errors.Add(message); } public bool HasErrors { get { return errors.Any(); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

特別なクラスを使用して、意図をより明確にします。読者は、アイデアとその実装の間にメンタルマップを作成する必要はありません。

Checkメソッドを分離する

最初の手順は、Checkメソッドを2つの部分に分割することです。内側の部分は通知のみを処理し、例外はスローしません。外側の部分は、エラーが検出された場合に例外をスローするCheckメソッドの現在の動作を保存します



「メソッドの選択」メソッドを使用して、Check関数の本体をValidation関数に移動します。

 public void heck() { Validation(); } public void Validation() { if (Date == null) throw new ArgumentNullException("  "); DateTime parsedDate; try { parsedDate = DateTime.Parse(Date); } catch (FormatException e) { throw new ArgumentException("    ", e); } if (parsedDate < DateTime.Now) throw new ArgumentException("     "); if (NumberOfSeats == null) throw new ArgumentException("   "); if (NumberOfSeats < 1) throw new ArgumentException("     "); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、Notificationの作成と関数からの戻り値を使用してValidationメソッドを拡張します。

 public Notification Validation() { var notification = new Notification(); //... return notification; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、通知を確認し、エラーが含まれている場合は例外をスローできます。

 public void heck() { var notification = Validation(); if (notification.HasErrors) throw new ArgumentException(notification.ErrorMessage); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

将来、ほとんどのユーザーがCheckよりもこのメソッドの使用を好むことが予想されるため、Validationメソッドをオープンにしました。



これまでのところ、コードの動作をまったく変更していないため、失敗した検証チェックはすべて例外をスローし続けますが、例外スローを通知に置き換え始めるためのベースを作成しました。

元のメソッドを分離することで、検証をその結果に対する反応から分離することができました。

続行する前に、エラーメッセージについていくつか説明する必要があります。 リファクタリングを行うとき、観察された動作の変化を避けることが重要です。 このルールは、どのような動作が観察可能かという問題につながります。 明らかに、例外をスローすることは外部プログラムが観察するものですが、エラーメッセージをどの程度気にしますか？ 通知は多くのエラーメッセージを収集し、たとえばこの方法で1つに結合します。

 public string ErrorMessage { get { return string.Join(", ", errors); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ただし、プログラムの上位層で問題が発生する可能性があり、最初のエラーのみを受信することに依存しています。 この場合、次のように実装する必要があります。

 public string ErrorMessage { get { return errors[0]; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

呼び出された関数だけでなく、既存のハンドラーも調べて、特定の状況での正しい動作を判断する必要があります。

番号検証

行うべき明らかなことは、最初のチェックを置き換えることです。

 public Notification Validation() { var notification = new Notification(); if (Date == null) notification.AddError("  "); //... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明らかな置き換えですが、コードを壊してしまうので悪いです。 Dateの引数としてnullを渡すと、Notificationオブジェクトにエラーが追加され、コードの実行が続行され、解析時にDateTime.ParseメソッドでNullReferenceExceptionが取得されます。 これは私たちが得たいものではありません。



この場合、自明ではないがより効果的な方法は、メソッドの最後から実行することです。

 public Notification Validation() { //... if (NumberOfSeats < 1) notification.AddError("     "); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次のチェックはnullチェックなので、条件を追加してNullReferenceExceptionを回避する必要があります

 public Notification Validation() { //... if (NumberOfSeats == null) notification.AddError("   "); else if (NumberOfSeats < 1) notification.AddError("     "); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、次のチェックには別のフィールドが含まれています。 また、これらのチェックは別のフィールドのチェックでも考慮する必要があります。 検証方法は複雑になりすぎています。 したがって、別のメソッドでNumberOfSeatsチェックを削除します。

 public Notification Validation() { //... ValidateNumberOfSeats(notification); } private void ValidateNumberOfSeats(Notification notification) { if (NumberOfSeats == null) notification.AddError("   "); else if (NumberOfSeats < 1) notification.AddError("     "); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

数字の強調表示された検証を見ると、あまり自然に見えません。 検証にif-then-elseブロックを使用すると、コードが過度にネストされやすくなります。 さらに進むことができない場合に壊れる線形コードを使用することはより好ましく、これはセキュリティ条件を使用して実装できます。

 private void ValidateNumberOfSeats(Notification notification) { if (NumberOfSeats == null) { notification.AddError("   "); return; } if (NumberOfSeats < 1) notification.AddError("     "); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メソッドの最後からコードを機能させたままにするという決定は、リファクタリングの基本原則を示しています。 リファクタリングは、一連の動作を維持する変換によってコードを再構築するための特別な手法です。 したがって、リファクタリングするときは、常に動作を維持する最小の手順を実行するようにしてください。 これにより、エラーの可能性が低くなります。

日付検証

日付のチェックを別の方法で保存することから始めます。

 public Notification Validation() { ValidateDate(notification); ValidateNumberOfSeats(notification); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、数値の場合と同様に、メソッドの最後から例外の置き換えを開始します。

 private void ValidateNumberOfSeats(Notification notification) { //... if (parsedDate < DateTime.Now) notification.AddError("     "); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スローされた例外には元の例外が含まれているため、次のステップでは例外をキャッチするのが少し難しくなります。 これを処理するには、Notificationクラスを変更して例外を受け入れる必要があります。



ExceptionパラメーターをAddErrorメソッドに追加し、既定値のnullを指定します。

 public void AddError(string message, Exception exc = null) { errors.Add(message); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

つまり、例外を受け入れますが、無視します。 どこかに配置するには、Notificationクラス内のエラーの種類を文字列からより複雑なオブジェクトに変更する必要があります。 Notification内にErrorクラスを作成します。

 private class Error { public string Message { get; set; } public Exception Exception { get; set; } public Error(string message, Exception exception) { Message = message; Exception = exception; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これでクラスができたので、それを使用するようにNotificationを変更する必要があります。

 //... private List<Error> errors = new List<Error>(); public void AddError(string message) { errors.Add(new Error(message, null)); } public void AddError(string message, Exception exception = null) { errors.Add(new Error(message, exception)); } //... public string ErrorMessage { get { return string.Join(", ", errors.Select(e => e.Message)); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しい通知が用意されたら、予約リクエストを変更できるようになりました。

 private void ValidateDate(Notification notification) { if (Date == null) throw new ArgumentNullException("  "); DateTime parsedDate; try { parsedDate = DateTime.Parse(Date); } catch (FormatException e) { notification.AddError("    ", e); return; } if (parsedDate < DateTime.Now) notification.AddError("     "); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後の変更は非常に簡単です。

 private void ValidateDate(Notification notification) { if (Date == null) notification.AddError("  "); DateTime parsedDate; try { parsedDate = DateTime.Parse(Date); } catch (FormatException e) { notification.AddError("    ", e); return; } if (parsedDate < DateTime.Now) notification.AddError("     "); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

おわりに

通知メカニズムを使用してメソッドを変換したら、次のタスクは、Checkメソッドが呼び出される場所を確認し、代わりにValidateを使用する可能性を検討することです。 これを行うには、検証がアプリケーションの現在の実装にどのように適合するかを分析する必要があります;これは、ここで説明するリファクタリングの範囲を超えています。 しかし、中期的には、検証エラーが予想される状況で例外の使用を除外するという目標があります。



多くの場合、これによりCheckメソッドが完全に削除されます。 この場合、このメソッドのテストは、検証メソッドを使用して更新する必要があります。 また、通知を通じて複数のエラーの正しいコレクションを検証するテストを追加することもできます。