ビジネスロジックでは不要なエラー処理が推奨されていますか？例えば。ヌルチェック/パーセンテージ制限チェックなど

Question

私たちは通常、障害を避けるためにビジネスロジックに不要なチェックを入れます。

例：我々はそれがnullになることはありませんことを確信している場合

1. public ObjectABC funcABC(){ 

     ObjectABC obj = new ObjectABC; 
    .......... 
    .......... 
    //its never set to null here. 
    .......... 
    return obj; 
} 

ObjectABC o = funABC(); 

if(o!=null){ 
//do something 
} 

は、なぜ我々は、このヌルチェックが必要なのでしょうか？ それは良い練習かどうかですか？

2. int pplReached = funA(..,..,..); 
    int totalPpl = funB(..,..,..); 

    funA() just puts a few more restriction over result of funB(). 


    Double percentage = (totalPpl==0||totalPpl<pplReached) ? 0.0 : pplReached/totalPpl; 

'totalPpl<pplReached'が必要ですか？

質問は次のとおりです。私たちは、そのような小切手を入れていくつかの根本的な問題を飲み込んでいませんか？理想的に示されるべき問題は、これらの小切手を置くことによって回避される。

推奨される方法は何ですか？

Answer 1

あなたの聴衆について考える。チェックが

は、プログラムが不正な入力または無効な状態から回復することができ、

は、他のプログラマは、コードがあなたを満たしているエラーを検出するのに役立ち、それは

1. あなたを助けたときに、プログラマは、エラーを検出価値があります、または
2. は、後でエラーが発生するのを避けるのに役立ちます。

あなたのnullのチェックがこれらに該当しない場合、または同じことを行う簡単なメカニズムがある場合は、それを放置してください。

簡単な機構は、しばしば、

1. ユニットテストを含みます。
2. リーダーに意思を伝え、コードが早期に失敗する原因findbugsまたは同様のツール
3. assert Sによって確認され、到達すべきではありませんエラー処理コードに置くためにあなたを必要とせずとせずに意思を伝えることができます注釈混乱のコード・カバレッジ・ツールは
4. ドキュメントまたはインラインコメントは
この場合

、私は注釈

public @Nonnull ObjectABC funcABC(){ 

に追加することを示唆しています

は、ビルドプロセスにFindBugsの統合、そして多分

assert o != null: "funcABC() should have allocated a new instance or failed." 

で

if(o!=null){ 
//do something 
} 

を交換するには、我々はこのようなチェックを入れて、いくつかの根本的な問題を飲み込むませんか？経験則として

、

1. 単体テストは、コードの小片の挙動を確認するために良好です。重要な機能の単体テストを書くことができない場合、基本的な問題は、あなたがwriting testable codeではないということです。
2. 注釈は、査読者、管理者、自動化されたツールの意図を伝達するのに適しています。これらのツールをプロセスに統合していない場合、基本的な問題は、利用可能なコード品質ツールを利用していないことです。
3. assertは、前提条件を再確認するのに適しています。あなたのコードにアサーションを振りかざすことができず、違反していることを素早く知ることができない場合、根本的な問題は、問題を揺るがすための代表的なデータに対してコードを実行する素早い方法がないことです。
4. チームの複数の担当者がコードのどの部分でも問題を解決できるように、ドキュメントとインラインコメント（ソース管理コメントを含む）は、チームに関するシステムに関する知識を広めるのに適しています。それらが絶えず欠けているか同期していない場合、根本的な問題はメンテナーを念頭に置いてコードを書くことではないということです。

最後に、design by contractは、多くの場合ビジネスロジックコードに役立つと判明したプログラミング方法です。チームに特定のツールとプラクティスを採用するよう説得することができない場合でも、DbCを読むことは、コードベースで重要なインバリアントを実行する方法を理由づけて説明するのに役立ちます。