問題タブ [preconditions]

頭のてっぺんから、null 引数をチェックする 4 つの方法を考えることができます。

私は常に最後の方法を使用してきましたが、Contract.Requires慣れていない を使用したコード スニペットを見ただけです。各方法の長所/短所は何ですか? 他の方法はありますか？

Resharper を使用した VS2010 では、

• Contract.Assert式が常に true であることを警告します (どのように知っているのか、よくわかりません... HttpContext を null にすることはできませんか?)、
• Contract.Requiresフェードアウトし、コンパイラーがメソッドを呼び出さないことがわかります (前の理由により、null になることはないと思います)。
• 最後のメソッドをcontext != null次のすべてのコードに変更すると、フェードアウトし、コードがヒューリスティックに到達できないことがわかります。

したがって、最後の 3 つのメソッドには、VS 静的チェッカーに何らかのインテリジェンスが組み込まれているようであり、Debug.Assert単に馬鹿げています。

私は最近、コードへの小さな変更が複数のクラスにわたって前提条件を変更するといういくつかのシナリオを経験しました。

goalStack.pop()スタックが空でないという前提条件がある場合getNextGoal()、同じ前提条件を明示的に持つ必要がありますか? 前提条件を継承すると物事が脆弱になり、キューまたはその他の構造に変更すると、前提条件がgetNextGoal()、呼び出し元、呼び出し元の呼び出し元に変更されるようです。しかし、前提条件を継承しないと、コントラクトと呼び出し元が隠され、呼び出し元の呼び出し元は前提条件についてわからないように思えます。

すべての呼び出し元が呼び出し元のコードの事前条件と事後条件を知って継承する脆弱なコードか、それともより深い事前条件と事後条件が何であるかを呼び出し元がまったく知らない不思議なコードですか?

私は「早期に失敗する」戦略のファンであり、たとえばメソッドパラメータが正しい値を持っていることを確認したいと思います。JavaではGuavaのようなものを使用します：

.NETに似たものはありますか？

私は前提条件とそれらをいつ使用するかについて学んでいます。前提条件は

次のコードには適合しません。

どうしてこれなの？

編集：別の例

例として、次のことが「正しい」方法で行われると想定しています。IllegalArgumentExceptionと前提条件に注意してください。動作がどのように明確に定義されているか、および前提条件が設定されている場合でもthrows宣言がどのように行われるかに注意してください。最も重要なことは、NullPointerExceptionの前提条件が含まれていないことに注意してください。もう一度、なぜそうではないのですか？

これらの例は、余分な前提条件の使用を回避していますか？前提条件を回避しているのなら、なぜそれらを持っているのでしょうか。つまり、すべての前提条件を@throws宣言に置き換えてみませんか（それらを回避することがここで行われている場合）？

前提条件コード コントラクトとして、参照型が null になるのを防ぐためのラッパー クラスを作成しました。

これは問題なく動作しますが、Nullable を扱うときのように常にキャストが必要です。

NonNullable 型のパラメーターをキャストせずに T 型のように動作させることは可能でしょうか? 仕様番号のように:

アサーションを使用するjUnitテスト（T1と呼びましょう）があります。そのアサーションが何らかの価値を持つためには、そのアサーションが正しいことを確認するバリデーターが必要です。

バリデーターについては、別のテストスイートにテスト (T2) があります。どうにかして T2 を T1 の前提条件にすることはできますか。

それが不可能な場合、T1 と T2 が同じスイートにあれば可能でしょうか?

私はグアバの前提条件が好きですが、それから本当に必要なのはもう1つの方法です-数が範囲内にあることを確認してください。このようなSmt

私は一人ではないと信じており、それはかなり一般的なケースです。しかし、そのような方法は存在しません。そのような方法を入れない理由はありますcom.google.common.base.Preconditionsか？

Warning 1 CodeContracts: requires unproven: Contract.ForAll(coll, item => item != null) C:\MyApp\MyObj.cs

古いバージョンの CodeContracts ではContract.ForAll()メソッドがサポートされていなかったことに気付きましたが、今では (ver 1.4.40602.0) サポートされると思いましたか? ここで何か間違ったことをしているだけですか、それともまだサポートされていませんか?

Agilian3.2を使用して小さなアクティビティ図を作成しています。この図には、いくつかのアクションが含まれています。問題は、図のどこかに前提条件を表示したいということです。Agilianでアクションまたはアクティビティ図の前提条件を定義する標準的な方法はありますか？

assertJavaキーワードは、製品コードで常に有効になっているとは限らないため、好きではありません。記載されているアサーションを常に実行する、使用する優れた「ProductionAssert」クラスを探しています。

候補の 1 つはGuava の Preconditionsです。それはまともですが、少し制限されています（たとえば、いいえ、、、assertEquals()）。assertNull()assertGreaterEquals()

代替手段の 1 つは、jUnit または別のテスト フレームワークを含めることですが、単純な assert クラスのためだけにテスト フレームワーク全体に依存することには消極的です。

Groovy でプログラミングする場合は、PowerAssertを使用します。

Java 用の適切な「ProductionAssert」クラスはありますか?

PS - 1 つのオプションは最終的にJava Contractsのようなものをチェックアウトすることです...しかし、私が今探しているのは、絶対に最小限で摩擦がなく、ビルドプロセスの種類のクラスを変更せずにドロップインするだけです。 .. 契約がその説明に適合するかどうかはわかりません。