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

コンピュータ プログラミングにおいて、特に命令型プログラミングパラダイムを使用する場合、アサーションとは、プログラム内のあるポイントに関連付けられた述語(状態空間上のブール値関数で、通常はプログラムの変数を使用して論理命題として表現される) であり、コード実行のそのポイントでは常に true と評価されます。アサーションは、プログラマがコードを読みやすくしたり、コンパイラがコードをコンパイルしやすくしたり、プログラムが自身の欠陥を検出しやすくしたりするのに役立ちます。

後者の場合、一部のプログラムは実行時に述語を実際に評価することでアサーションをチェックします。そして、それが実際には真でない場合（アサーション失敗）、プログラムはそれ自体が壊れているとみなし、通常は意図的にクラッシュするか、アサーション失敗例外をスローします。

次のコードにはx > 0と という2 つのアサーションが含まれておりx > 1、実行中の指定されたポイントでは実際に真になります。

x = 1 ; x > 0をアサート; x ++ ; x > 1 をアサート;  
   

   

プログラマーは、アサーションを使用してプログラムを指定し、プログラムの正しさを推論することができます。たとえば、前提条件(コード セクションの先頭に配置されるアサーション) は、プログラマーがコードの実行を期待する一連の状態を決定します。事後条件(末尾に配置される) は、実行終了時に期待される状態を記述します。例: x > 0 { x++ } x > 1。

上記の例では、CAR Hoareが1969 年の論文で使用したアサーションの表記法を使用しています。[ ^{1]この表記法は、既存の主流のプログラミング言語では使用できません。ただし、プログラマーはプログラミング言語の}コメント機能を使用して、チェックされていないアサーションを含めることができます。たとえば、C++では次のようになります。

x = 5 ; x = x + 1 ; // {x > 1}  
    

コメントに含まれる中括弧は、このコメントの使用法を他の使用法と区別するのに役立ちます。

ライブラリはアサーション機能も提供する場合があります。たとえば、C99 をサポートする glibcを使用した C では次のようになります。

#include <assert.h> 

int f ( void ) { int x = 5 ; x = x + 1 ; assert ( x > 1 ); } 

       
        
      

最近のプログラミング言語には、チェックされたアサーション (実行時または場合によっては静的にチェックされるステートメント) が含まれているものがあります。実行時にアサーションが false と評価されると、アサーション エラーが発生し、通常は実行が中止されます。これにより、論理的な矛盾が検出された場所が注目され、そうでない場合の動作よりも好ましい場合があります。

アサーションを使用すると、プログラマーはプログラムを設計、開発、および推論しやすくなります。

Eiffelなどの言語では、アサーションは設計プロセスの一部を形成します。CやJavaなどの他の言語では、アサーションは実行時に仮定をチェックするためにのみ使用されます。どちらの場合も、実行時にアサーションの有効性をチェックできますが、通常は抑制することもできます。

アサーションはドキュメントの形式として機能することができます。アサーションは、コードが実行される前の状態 (前提条件) と、コードの実行が終了したときに予想される状態 (事後条件) を記述できます。また、クラスの不変条件を指定することもできます。Eiffelは、このようなアサーションを言語に統合し、自動的に抽出してクラスをドキュメント化します。これは、契約による設計手法の重要な部分を形成します。

このアプローチは、明示的にサポートされていない言語でも役立ちます。コメント内のアサーションではなくアサーション ステートメントを使用する利点は、プログラムが実行されるたびにアサーションをチェックできることです。アサーションが保持されなくなった場合は、エラーを報告できます。これにより、コードがアサーションと同期しなくなるのを防ぐことができます。

アサーションは、プログラムの実装中にプログラマーが行った仮定が、プログラムの実行時にも有効であることを確認するために使用できます。たとえば、次のJavaコードを考えてみましょう。

 int total = countNumberOfUsers (); if ( total % 2 == 0 ) { // total は偶数です} else { // total は奇数で負ではありませんassert total % 2 == 1 ; }   
       
     
   
     
          
 

Javaでは、は剰余演算子 (を法とする%)であり、Java では、最初のオペランドが負の場合、結果も負になる可能性があります (数学で使用される法とは異なります)。ここで、プログラマーは が負ではないと想定しているため、2 での除算の剰余は常に 0 または 1 になります。アサーションはこの想定を明示的に示しています。 が負の値を返す場合、プログラムにバグがある可能性があります。 totalcountNumberOfUsers

この手法の主な利点は、エラーが発生した場合、後になってわかりにくい影響を通じてエラーが検出されるのではなく、すぐに直接検出されることです。アサーションの失敗では通常、コードの場所が報告されるため、それ以上デバッグしなくてもエラーを正確に特定できることがよくあります。

アサーションは、実行が到達するはずのないポイントに配置されることもあります。たとえば、C、C++、Javaなどの言語では、アサーションはステートメントdefaultの節に配置されることがあります。プログラマが意図的に処理しなかった場合はエラーが発生し、プログラムはエラー状態で黙って続行されるのではなく中止されます。Dでは、ステートメントに節が含まれていない場合、このようなアサーションが自動的に追加されます。 switchswitchdefault

Javaでは、アサーションはバージョン 1.4 以降言語の一部となっています。AssertionError適切なフラグを指定してプログラムを実行すると、アサーションが失敗すると が発生し、フラグを指定しないとアサート文は無視されます。Cでは、標準ヘッダーによって が追加され、失敗時にエラーを通知するマクロとしてassert.h定義され、通常はプログラムが終了します。C++では、と の両方のヘッダーがマクロを提供します。 assert (assertion) assert.hcassertassert

アサーションの危険性は、メモリ データの変更またはスレッド タイミングの変更によって副作用が発生する可能性があることです。アサーションは、プログラム コードに副作用が発生しないように慎重に実装する必要があります。

言語内のアサーション構造により、サードパーティのライブラリを使用せずに テスト駆動開発(TDD) を簡単に行うことができます。

開発サイクル中、プログラマは通常、アサーションを有効にしてプログラムを実行します。アサーション エラーが発生すると、プログラマはすぐに問題を通知されます。多くのアサーション実装では、プログラムの実行も停止します。これは、アサーション違反が発生した後もプログラムの実行が継続されると、プログラムの状態が破壊され、問題の原因の特定が困難になる可能性があるため、便利です。アサーション エラーによって提供される情報 (エラーの場所やスタック トレース、または環境がコア ダンプをサポートしている場合やプログラムがデバッガで実行されている場合は完全なプログラム状態など) を使用して、プログラマは通常、問題を修正できます。このように、アサーションはデバッグにおいて非常に強力なツールを提供します。

プログラムが本番環境にデプロイされると、オーバーヘッドや副作用を回避するために、アサーションは通常オフになります。マクロを介したC/C++アサーションなど、デプロイされたコードにアサーションがまったく存在しない場合もあります。Javaなどの他のケースでは、デプロイされたコードにアサーションが存在し、現場でデバッグのためにオンにすることができます。^[2]

アサーションは、特定のエッジ条件が実際には到達不可能であることをコンパイラーに保証するためにも使用され、それによって、そうでなければ不可能な特定の最適化が可能になります。この場合、アサーションを無効にすると、実際にはパフォーマンスが低下する可能性があります。

コンパイル時にチェックされるアサーションは、静的アサーションと呼ばれます。

静的アサーションは、コンパイル時のテンプレート メタプログラミングで特に便利ですが、アサーションが失敗した場合 (そしてその場合のみ) に不正なコードを導入することで、C などの低レベル言語でも使用できます。C11およびC++11 は、を通じて直接静的アサーションをサポートします。以前のCバージョンでは、静的アサーションは次のように実装できます。 static_assert

#define SASSERT(pred) switch(0){case 0:case pred:;}

SASSERT (ブール条件);   

部分が false と評価された場合、コンパイラは同じ定数を持つ 2 つのcase ラベルを(BOOLEAN CONDITION)許可しないため、上記のコードはコンパイルされません。ブール式はコンパイル時の定数値である必要があります。たとえば、そのコンテキストでは有効な式になります。この構造はファイル スコープ (つまり、関数内ではない) では機能しないため、関数内にラップする必要があります。 (sizeof(int)==4)

C言語でアサーションを実装するもう一つの一般的な方法 ^{[3]は次の通りです。}

static char const static_assertion [ (ブール条件) ? 1 : -1 ] = { '!' };     
                                       
                                    

部分が false と評価された場合(BOOLEAN CONDITION)、配列の長さが負になることはできないため、上記のコードはコンパイルされません。実際にコンパイラが負の長さを許可する場合、初期化バイト ('!'部分) は、そのような過度に寛容なコンパイラでさえもエラーを発するはずです。ブール式はコンパイル時の定数値である必要があります。たとえば、(sizeof(int) == 4)そのコンテキストでは有効な式になります。

どちらの方法でも、一意の名前を構築する方法が必要です。最近のコンパイラは、__COUNTER__コンパイル単位ごとに単調に増加する数値を返すことで一意の名前の構築を容易にするプリプロセッサ定義をサポートしています。^[4]

Dは静的アサーションを提供しますstatic assert。^[5]

ほとんどの言語では、アサーションをグローバルに有効または無効にできます。また、個別に有効または無効にすることもできます。アサーションは、開発中は有効にされ、最終テスト中および顧客へのリリース時には無効にされることがよくあります。アサーションをチェックしないことで、アサーションを評価するコストを回避できますが、(アサーションに副作用がないと仮定すると) 通常の条件下では同じ結果が生成されます。異常な条件下では、アサーション チェックを無効にすると、中止されるはずだったプログラムが引き続き実行される可能性があります。この方が望ましい場合もあります。

C、YASS、C++ などの一部の言語では、プリプロセッサを使用してコンパイル時にアサーションを完全に削除できます。

同様に、引数として「-O」（「最適化」の略）を指定してPythonインタープリターを起動すると、Pythonコードジェネレーターはアサート用のバイトコードを生成しなくなります。^[6]

Java では、アサーションを有効にするために、ランタイム エンジンにオプションを渡す必要があります。オプションがない場合、アサーションはバイパスされますが、実行時に JIT コンパイラによって最適化されるか、プログラマが各アサーションを句の後ろに手動で配置してコンパイル時に除外されない限り、アサーションは常にコード内に残りますif (false)。

プログラマーは、言語の通常のアサーション チェック メカニズムをバイパスまたは操作することで、常にアクティブなチェックをコードに組み込むことができます。

アサーションは、通常のエラー処理とは異なります。アサーションは、論理的にあり得ない状況を文書化し、プログラミング エラーを検出します。あり得ないことが発生した場合、プログラムに根本的な間違いがあることは明らかです。これはエラー処理とは異なります。ほとんどのエラー状態は起こり得ますが、実際にはほとんど発生しないエラー状態もあります。アサーションを汎用のエラー処理メカニズムとして使用するのは賢明ではありません。アサーションではエラーからの回復ができず、アサーションが失敗すると通常、プログラムの実行が突然停止し、製品コードではアサーションが無効になっていることがよくあります。アサーションでは、ユーザー フレンドリなエラー メッセージも表示されません。

アサーションを使用してエラーを処理する次の例を考えてみましょう。

  int * ptr = malloc ( sizeof ( int ) * 10 ); assert ( ptr ); // ptr を使用します...     
  
  
  

ここで、プログラマーは、メモリが割り当てられていない場合はがポインターmallocを返すことを認識しています。これはあり得ることです。オペレーティング システムは のすべての呼び出しが成功することを保証しません。メモリ不足エラーが発生すると、プログラムは直ちに中止されます。アサーションがなければ、プログラムは が参照解除されるまで実行を継続し、使用されている特定のハードウェアによっては、さらに長い時間実行される可能性があります。アサーションが無効になっていない限り、即時終了が保証されます。ただし、正常な失敗が望ましい場合は、プログラムで失敗を処理する必要があります。たとえば、サーバーに複数のクライアントがある場合や、正常に解放されないリソースが保持されている場合、またはデータストアに書き込むコミットされていない変更がある場合があります。このような場合は、突然中止するよりも、単一のトランザクションを失敗させる方が適切です。 NULLmallocptr

もう 1 つのエラーは、アサーションの引数として使用される式の副作用に頼ることです。アサーションの唯一の目的は、常に真であるべき条件が実際に真であることを確認することであるため、アサーションがまったく実行されない可能性があることを常に念頭に置く必要があります。その結果、プログラムにエラーがないと判断され、リリースされた場合、アサーションは無効になり、評価されなくなります。

前の例の別のバージョンを考えてみましょう。

  int * ptr ; // 以下のステートメントは、malloc() が NULL を返す場合は失敗しますが、// -NDEBUG! でコンパイルするとまったく実行されません。assert ( ptr = malloc ( sizeof ( int ) * 10 )); // ptr を使用します。-NDEBUG! でコンパイルすると、ptr は初期化されません。... 
  
  
      
  
  

mallocこれは、戻り値をに割り当ててptr、それがNULL1 つのステップでチェックする賢い方法のように見えるかもしれませんが、malloc呼び出しと への割り当ては、条件ptrを形成する式を評価する副作用ですassert。NDEBUGプログラムにエラーがないと見なされてリリースされたときのように、パラメーターがコンパイラに渡されると、ステートメントは削除されるassert()ため、malloc()呼び出されず、初期化されていない状態になります。これにより、プログラム実行のずっと後の段階でセグメンテーション違反または同様のnull ポインターエラーが発生する可能性があります。これにより、散発的または追跡が困難なバグが発生する可能性があります。プログラマーは、この問題を軽減するために、同様の VERIFY(X) 定義を使用する場合があります ptr。

最近のコンパイラは上記のコードに遭遇すると警告を発することがある。^[7]

1947年にフォン・ノイマンとゴールドスタインがIASマシンの設計について発表した報告書^[8]では、フローチャートの初期バージョンを使用してアルゴリズムが説明されており、そこには次のようなアサーションが含まれていました。「Cがフロー図の特定のポイントに到達すると、1つ以上のバインドされた変数が必ず特定の値を持つか、特定のプロパティを持つか、互いに特定のプロパティを満たすことは事実です。さらに、そのようなポイントで、これらの制限の有効性を示すことができます。このため、このような制限の有効性が主張されている各領域を、アサーションボックスと呼ぶ特別なボックスで示します。」

プログラムの正しさを証明するアサーション法は、アラン・チューリングによって提唱された。1949年6月24日、ケンブリッジでの講演「大規模ルーチンのチェック」で、チューリングは次のように提案した。「大規模なルーチンが正しいことを確かめるにはどうすればいいだろうか。チェックする人があまり困難な作業にならないように、プログラマーは個別にチェックでき、プログラム全体の正しさが簡単にわかるような明確なアサーションをいくつか作成する必要がある」。^[9]

• アサーション定義言語
• 契約による設計
• 例外処理
• ホーア論理
• 静的コード分析
• Javaモデリング言語
• 不変量（コンピュータサイエンス）

• ソフトウェア開発における実行時アサーション チェックの歴史的観点(Lori A. Clarke、David S. Rosenblum 著) ACM SIGSOFT Software Engineering Notes 31(3):25-37、2006
• アサーション: CAR Hoare による個人的な視点、IEEE Annals of the History of Computing、巻: 25、号: 2 (2003)、ページ: 14 - 25
• 私のコンパイラは私を理解してくれない、 Poul-Henning Kamp著、ACM Queue 10(5)、2012年5月
• John Regehr によるアサーションの使用