Javaでどの例外を投げるようコーディングすべきかについてちょっと書いてみた。
言いたかった事は「NullPointerExceptionをスローするようなコーディングはするな」という事だけだったんだけど、体裁を整えていたら長くなってしまった＾＾；
（IllegalArgumentExceptionを知らない人は居ないと思うけど、IllegalStateExceptionとかは知らない人が居そうだし）
ついでに、例外の基礎のページに例外の概要を追加した。
初めてJavaの例外を勉強した頃（2003年）は、まずは使い方（文法）を調べるということで、とりあえず試した事を書いただけだった。
C++にもtry-catchがあるのは知ってたんだけど使い方はよく分からず、Javaで試してみて初めて理解したという感じだし(苦笑)
あの頃は例外に関する説明を書く知識なんて無かったからなぁ。9年近く経って、ようやく概要くらいは書けるようになったわけだ。
…進化が遅いな＾＾；（しかも間違ってたりして(爆)）
引数が間違っているから異常終了するぜ！というコーディングは、Javaだと例外を投げればいいが、C言語だとexit()を呼ぶことが多いと思う。
で、「exit()することを確認するテスト」をCutterで実施する方法を考えてみた。
C言語はマクロを使えるので、exit()をlongjmp()に置き換えてしまえ、という荒業(笑)
C言語のマクロはほんと強力だわ＾＾；
ただ、setjmp/longjmpは、使い方を誤ると訳の分からない状態になる。
Cutterだとテストの関数をたくさん作ることになるので、それぞれでちゃんとsetjmp()しないと、あるテストでexit（longjmp）したら“別のテスト時にsetjmpした場所”へ跳んでしまった、なんて事が起こりうる。もしそうなったらチンプンカンプンな結果になるので、テストのデバッグをしないといけなくなる。大変ですぜーorz
Javaでの開発はJUnitでテストするのが当たり前になっているので、C言語でもそれっぽいもので単体テストしたい。
（自分でテストフレームワークっぽいものを作ろうと思えば作れるけど、さすがに面倒だし）
CUnitというものが世の中にはあるようだけど、同じCUnitという名前でも何人かが作っていて異なっているらしい＾＾；
そんな中、CUnitよりもCutterの方が良いという意見をちらほら目にしたので、Cutterを試してみた。
そしたら、なるほど、これは便利！
assert関数はJUnit3に似ていて分かり易いし、種類が豊富に揃っている。
テスト実行関数も自動的に収集してくれるので、main()に自分でテスト関数呼び出しを書いたりする必要も無い。
テスト結果も見やすい。（テスト失敗時には値とソースの場所まで出てくれる！）
ドキュメントも日本語でかなりの分量が書かれている。
惜しむらくは、ドキュメントのチュートリアルが複雑すぎることか＾＾；
「テストは自動で繰り返し行えるようにするものだ」という意思はひしひしと伝わってくるのだが、その為にacファイルとかamファイルとか（聞いたことないよ）を用意しなければならないように見えて、敷居が高そうに感じられてしまうorz
これに関しては『凡人プログラマーの独り言 Cutterのとても簡単な使い方』が非常に分かり易かった。最小限のCutterは拍子抜けするほど簡単だったｗ
で、それを参考に自分でもmakefileを作ってみた。（さすがに毎回gccコマンドを手で叩くのが良いとは思えないし）
makefileを書くのは久しぶりだったんだけど、ちょっと調べてみたら今さらながら知らない機能があるのにびっくりした＾＾；
テキスト変形関数って、超便利！
指定ディレクトリー内の*.cファイルの一覧を変数に入れるとか、UNIXコマンドを実行した結果を変数に入れるとかが出来る。
昔はこのやり方を知らなくて、makefile内にファイル一覧とかをいちいち書いてたんだよなぁ。ちくしょーｗ
Asakusa Frameworkのアーキタイプの概要を書いてみた。
Asakusa Framework0.4を試してみようと思ったらまずインストールする必要がある（当然ｗ）が、Mavenとかを事前にインストールしなきゃならない。
まぁMavenの使い方を知らなくても色々なサイトに説明があるから調べられなくはないし、Jinrikishaを使えばMavenとかもインストールしてくれるので気にしなくて大丈夫。
しかし、どの方法でインストールするにせよ、途中で訊かれる「Asakusa Frameworkのアーキタイプ」については、Asakusa Frameworkを知ってないと選択できない。
自分も初めてAsakusaFWをインストールした時はどれを選べばいいのか迷ったし＾＾；
という訳で、試しに触ってみたい・初めて使ってみるという人へのアドバイスとしては、
・基本的にはWindGate
・RDBもローカルファイルも扱わない（HDFS上のファイルだけ扱う）と分かっているならDirect I/O
かな。
（バージョンについては、選択肢の中に出てくる最も新しいもの、ただし「SNAPSHOT」が付いていないやつが良いでしょう）
WindGateアーキタイプは、実はDirect I/Oの機能もそのまま含んでいる（というか、Direct I/Oが中核機能）。
したがって、WindGateアーキタイプを選んでDirect I/Oの機能しか使わないということも可能。（両方の機能を使うことも可能。DMDLのアノテーションをモデル毎に変えればいいだけ）
逆にDirect I/Oアーキタイプを選んで後からWindGateの機能を使いたいとなった場合は、色々設定を変更しなきゃいけなくて面倒。
だったら最初からWindGateを選んどきゃいーじゃん、という話ｗ
最初の頃、自分はWindGateとDirect I/Oでのファイルの扱い方の違いが分からなかった＾＾；
開発環境（自分のマシン上のEclipseのJUnit（AsakusaFWのテストドライバー））でAsakusaアプリを実行してみる分には、DMDLのアノテーションの記述方法やファイルのImporter/Exporterの記述方法の違いくらいしか無いんだもん。
テストドライバーはデフォルト状態でもちゃんと動くように出来ているから、「ローカルにテスト用のファイルが作られて読み書きしてるなー」という認識でしかなかったorz
本番環境（Hadoopクラスター）を意識して、初めて本当の違いが分かる。
この辺りはAsakusa Framework-RDBMS連携方法の資料が参考になるかも？ｗ #ステマ
