nDiki : Java の assertion

Java の assertion

Java では assertion 機能は J2SE 1.4 で導入された。

assertion を有効化する

コンパイル(Javac)

assert を使う場合は

 javac -source 1.4 ...

とする。

コンパイル (Ant)

Javac タスクの source 属性で 1.4 を指定する。

 <javac srcdir="." source="1.4" />

実行 (java)

実行時に -ea (-enableassertions) オプションを指定する。 システムクラス内のアサーションも有効にするには -esa (-enablesystemassertions) オプションを使用する。

実行 (Ant)

Junit タスクで assertion を有効にするには junit の fork 属性を yes にし、 jvmarg 子要素で -ea オプションを指定する。

 <junit fork="yes">
  <jvmarg value="-ea" />
 </juni>

実行 (Tomcat)

catalina.sh start する前に環境変数 JAVA_OPTS に -ea オプションを指定する。

関連情報

スポンサード リンク

2004年5月16日 (日)

assertion

昼食の時に話題になったので、考えてみた。

assertion を書いているか? いつ書くか?

最初からあまり書くことはない。 大抵、デバッグ中に書く。

ただし assertion を埋め込むようなデバッグをした次のコーディングフェーズでは、結構書く(長続きはしない)。

契約による設計をしたいと思いつつ、場当たり的。

C++ の時

最初に、自前の assert 処理を定義する(assert 関連マクロ、例外クラス、assertion を評価する関数など)。

比較的 assertion を埋め込む。

Java の時

うーん。C++ の時ほどは書かないかな。

 assert a_obj != null;

とか書いていて後で「あまり意味ないな」って思ったり。 C++ だと assertiion でチェックしておかないと発見が遅れる場合があるが、Java だと NullPointerException が吐かれるから大抵気がつくから。

Perl の時

簡単に無効化できないという意識があるためほとんど書かない。 大規模なパッケージの場合は、Makefile.PL を実行する際デバッグフラグを立てると make 時にコメントアウトされている assertion を有効にするようにソースコードを書き換える。

assertion を書くのをためらう時

  • assertion の条件式の計算がヘビーな時
  • assertion でチェックする条件の値を求めるのが面倒な時(ループを回さなければならないとか)
  • 本来のコードより assertion の方がずっと多くてコードが読みにくくなる場合
  • return 文が複数ある時(事後条件)
  • 他のメソッドの戻り値を直接 return してしまう時(事後条件)
スポンサード リンク
[ 5月16日全て ]

About Me

Naney Naney

Naney (なにい)です。株式会社ミクシィで SNS 事業の部長をしています。

About nDiki

nDiki1999年1月に始めたコンピュータ日誌を前身とする NaneyWeb 日記(兼パーソナルナレッジベース)です。

#nNote タグがついている記事は他の記事に比べて、より断片的・未整理・不完全なちょっとしたノートです。まだ結論に至っていない考えなども含まれます。頻繁/大幅に更新したり削除したりすることがあります。

※本サイトの内容は個人的見解であり所属組織とは関係ありません。

Other Notes

ナレッジベースアプリケーション Obsidian で書いているノートの一部を notes.naney.org で 公開しています。

最近検索されている記事

月別インデックス
Process Time: 0.046556s / load averages: 0.55, 0.57, 0.63
nDiki by WATANABE Yoshimasa (Naney)
Powered by DiKicker