実際、NSAssertのポイントは何ですか？

なぜなら、私が認識しているのは、アサーションが失敗するとアプリがクラッシュするということだけです。それがNSAssertを使用する理由ですか？それとも他に何の利点がありますか？そして、NSAssertをコードで私が想定する仮定のすぐ上に置くのは正しいことです。たとえば、パラメーターとして-1を受け取ってはならないが、-0.9または-1.1の可能性がある関数のようなものでしょうか。

アサートとは、値が想定どおりであることを確認することです。アサーションが失敗した場合は、何か問題が発生したためにアプリが終了します。アサートを使用する1つの理由は、渡されたパラメーターの1つが正確に特定の値（または値の範囲）でない場合に動作しないか、非常に悪い副作用を引き起こす関数がある場合、アサートを作成することができますその値が期待どおりであることを確認してください。そうでない場合は、何かが本当に間違っているため、アプリが終了します。アサートは、デバッグ/ユニットテストに非常に役立ちます。また、フレームワークを提供して、ユーザーが「悪質な」ことをするのを防ぐフレームワークを提供する場合にも役立ちます。

NSAssertは実際には話せませんが、Cのassert（）と同様に機能すると思います。

assert（）は、コードでセマンティックコントラクトを強制するために使用されます。それはどういう意味ですか、あなたは尋ねますか？

まあ、それはあなたが言ったようなものです：-1を受け取るべきではない関数がある場合、assert（）でそれを強制することができます：

void gimme_positive_ints（int i）{
  assert（i> 0）;
}

そして今、あなたはこのような何かをエラーログ（またはSTDERR）に見るでしょう：

アサーションi> 0が失敗しました：ファイルexample.c、2行目

そのため、潜在的に悪い入力から保護するだけでなく、有用な標準的な方法でそれらを記録します。

ああ、少なくともCではassert（）はマクロだったので、リリースコードでassert（）を何もしないものとして再定義できました。それがNSAssert（またはassert（））に当てはまるかどうかはわかりませんが、これらのチェックをコンパイルすることはかなり役に立ちました。

NSAssertアプリをクラッシュさせるだけではありません。クラス、メソッド、およびアサーションが発生した行がわかります。すべてのアサーションは、NS_BLOCK_ASSERTIONSを使用して簡単に非アクティブ化することもできます。したがって、デバッグに適しています。一方、投げるNSExceptionだけでアプリがクラッシュします。また、例外の場所についても通知されず、単純に無効にすることもできません。下の画像の違いをご覧ください。

NSAssertのドキュメントに記載されているように、アサーションでも例外が発生するため、アプリがクラッシュします。

アサーションハンドラーが呼び出されると、メソッド名とクラス名（または関数名）を含むエラーメッセージが出力されます。次に、NSInternalInconsistencyException例外が発生します。

NSAssert：

NSException：

上記の誰もが言ったこととは別に、NSAssert()（Cとは異なりassert()）のデフォルトの動作は例外をスローすることで、これをキャッチして処理することができます。たとえば、Xcodeはこれを行います。

明確にするために、誰かが言及したが完全には説明されていないように、カスタムコードを作成するだけでなくアサートを使用する理由（たとえばifsを実行し、不良データに対して例外を発生させる）は、本番アプリケーションではアサートを無効にする必要がある（SHOULD）ことです。

開発およびデバッグ中に、エラーをキャッチするためにアサートが有効になります。アサートがfalseと評価されると、プログラムは停止します。ただし、本番用にコンパイルする場合、コンパイラーはアサーションコードを省略し、実際にプログラムの実行を高速化します。それまでに、うまくいけば、すべてのバグが修正されました。プロダクション中にプログラムにまだバグがある場合（アサーションが無効でプログラムがアサーションを「スキップ」する場合）、プログラムはおそらく他の時点でクラッシュすることになります。

NSAssertのヘルプから：「プリプロセッサマクロNS_BLOCK_ASSERTIONSが定義されている場合、アサーションは無効になります。」したがって、マクロを配布ターゲットに配置するだけです[のみ]。

NSAssert（およびそれに相当するstdlib assert）は、開発中にプログラミングエラーを検出します。プロダクション（リリース済み）アプリケーションで失敗するアサーションはありません。したがって、正の引数を必要とするメソッドに負の数を決して渡さないと主張するかもしれません。テスト中にアサーションが失敗する場合は、バグがあります。ただし、渡された値がユーザーによって入力された場合、本番環境でのアサーションに依存するのではなく、入力の適切な検証を行う必要があります（無効にするリリースビルドに#defineを設定できます）NSAssert*。

アサーションは通常、特定のメソッドまたはロジックの一部の使用目的を強制するために使用されます。ゼロより大きい2つの整数の合計を計算するメソッドを書いていたとしましょう。メソッドが常に意図したとおりに使用されていることを確認するために、おそらくその条件をテストするアサートを配置します。

短い答え：彼らはあなたのコードが意図されたようにのみ使用されることを強制します。

ランタイムチェックのほかに、アサートプログラミングは、契約に基づいてコードを設計するときに使用される重要な機能であることを指摘しておくことは価値があります。

アサーションおよび契約による設計の詳細については、以下を参照してください。

アサーション（ソフトウェア開発）

契約による設計

アサーションを使用したプログラミング

契約による設計、例による[ペーパーバック]

彼の質問に完全に答えるために、あらゆるタイプのアサートのポイントはデバッグを支援することです。ソースでエラーをキャッチし、クラッシュの原因となったときにデバッガーでエラーをキャッチする方が価値があります。

たとえば、関数に値を渡す場合、特定の範囲の値が必要です。関数は、後で使用するために値を保存し、後で使用するとアプリケーションがクラッシュします。このシナリオで見られる呼び出しスタックは、不正な値の原因を示していません。誰が悪い値を渡しているのか、なぜそうなのかを知るために、悪い値をキャッチする方が良いでしょう。

NSAssert条件と一致したときにアプリをクラッシュさせます。条件と一致しない場合、次のステートメントが実行されます。以下のEXを探します。

私はただのタスクをテストするアプリを作成しますNSAssert：

    - (void)viewDidLoad {
    [super viewDidLoad];
    // Do any additional setup after loading the view, typically from a nib.
    [self testingFunction:2];
}

-(void)testingFunction: (int)anNum{
    // if anNum < 2 -> the app will crash
    // and the NSLog statement will not execute
    // that mean you cannot see the string: "This statement will execute when anNum < 2"
    // into the log console window of Xcode
    NSAssert(anNum >= 2, @"number you enter less than 2");
    // If anNum >= 2 -> the app will not crash and the below 
    // statement will execute
    NSLog(@"This statement will execute when anNum < 2");
}

私のコードにアプリがクラッシュすることはありません。テストケースは次のとおりです。

• anNum > = 2->アプリはクラッシュせず、ログ文字列が表示されます。 "このステートメントは、anNum <2"のときにoutPutログコンソールウィンドウに実行されます
• anNum <2->アプリがクラッシュし、ログ文字列が表示されない： "このステートメントはanNum <2のときに実行されます"