表明 (プログラミング)
開発中、プログラマは表明を入れた状態でプログラムを実行する。表明違反が発生すると、プログラマに即座に問題が通知される。ほとんどの表明の実装ではプログラムの実行も停止する。プログラムがそのまま実行を続けてしまうと問題の原因を究明することが困難となる可能性が高い。表明違反で表示される情報(違反発生箇所やスタックトレース)を使えば、プログラマは容易に問題を解決できる。このようにして表明はデバッグ工程を単純化する。
コンパイル時にチェックされる表明は静的表明と呼ばれる。静的表明は言語規格で規定されていない数値型のサイズをコンパイル時にチェックするといった用途のほか、コンパイル時のテンプレートメタプログラミングに特に有効である。D言語は静的表明 static assert をサポートしている。また、C++ではC++11規格において static_assert が導入された。C言語でもC11規格で _Static_assert が導入された。
旧規格のC/C++でも、表明違反となったときのみ不正なコード(コンパイルエラーとなるコード)が導入されるようにすることで、静的表明を実装可能である。例えば、C言語では次のように静的表明を実装できる。
(BOOLEAN CONDITION) が偽と評価されると、switch文の2つ目のラベルの値はゼロとなるため、コンパイラは2つのcaseラベルが同じ値だとしてエラーを検出する。なお、指定する式はコンパイル時に値が定まるものでなければならない。
表明とエラー処理ルーチンを区別することには意味がある。表明は論理的にありえない状況をチェックするのに使うべきである。もし、「ありえない」ことが起きたとしたら、根本的に何かが間違っていたということである。エラー処理は通常発生しうるエラーを処理する(もちろん、一部の状況はほとんど「ありえない」かもしれない)。表明をあらゆるエラー処理に使用するのは賢明ではない。表明ではエラーからの復旧が考慮されておらず、表明違反は無条件でプログラムを停止させてしまう場合がほとんどである。表明はユーザー向けのエラーメッセージも表示しない。
エラー処理に表明を使っているC言語の例を以下に示す。
ここで、プログラマは malloc が NULL を返す場合があることに気づいている(メモリを確保できなかった場合)。オペレーティングシステムは malloc が常に成功することは保証していない。したがってプログラムはメモリ確保失敗に対処すべきである。この例では表明は最良の選択ではないだろう。というのも、malloc の失敗は論理的にありえないことではないからである。大抵のケースでは滅多に発生しないが、特に大量のメモリを使用するソフトウェアでは、リソースの枯渇により新たな動的メモリ確保の失敗が容易に発生しうるため、設計上考慮すべき可能性である。
表明は有効化/無効化を切り替えられるよう多くの言語で実装されている。表明は本来、開発ツールであるため、最終テストおよびリリース時には無効化する。したがって有効化時/無効化時の違いがプログラムの意味的な違いを生じないことが前提にある。換言すれば、表明は副作用を持っていてはならない。
CやC++を含む多くの言語では、表明は、リリースコンパイル時にプリプロセッサによって完全に除去される。Javaでは、表明を有効化する場合、実行時にオプションの指定を必要とする。オプションの指定がない場合、表明は無視される。