| 著作一覧 |
なんて題だが例によって勝手な考察だ。
VBだとon resume nextとか書いて、「どうです死ななくなりましたよ」と胸をはるというお話（都市伝説かも）をどっかのサイトで見かけたが、この「死ななくなった」というのがキーなのかなと。
例によって、
try {
ResultSet rs = preparedStatement.executeQuery();
...
rs.close();
preparedStatement.close();
} catch (SQLException e) {
} // っていうか、finally節の存在を知らんのか？
みたいなのを書くプログラマってどうして、こういうのを書くんだろうか？ と考えてたわけだ。
ちなみに、こういうのは僕は書くけど。
try {
... // throw させてしまう
} finally {
try { ps.close() } catch (SQLException e) {} // 飲み込む
}
まあ、清濁併せ呑む気概というわけではなく、例外の上書きがイヤだからだ。closeでバッファフラッシュが行われたりするIOExceptionの場合と異なり、executeQueryについては、closeで例外になっても別に構わない。その後にどうせ死ぬわけだし、必要な情報はすでに取ってしまっている。一方、更新系の場合は、commitでどうせエラーがわかるからそれで良い。commitかrollbackするまではどうせ実際の更新は求めていないからだ。
でもそういうのと違うんだよね、最初の例のは。
で、例外というのは、プログラムのバグではなく（そういうのもあるけど）、特にIOExceptionとSQLExceptionなんかについては、ハードウェアや環境によって発生するプログラムから見れば天災のような例外なのだが、どうも飲み込んじゃうプログラマーというのは、例外＝オレのバグみたいに思っているか、またはそういうふうに思われると思っていて、とにかく自分が作ったプログラムの上を通り過ぎればそれで万事快調と考えてしまうのでは無いか？ と思いついた。
脳内妄想として、「バカヤロー、例外でシステムが逝ったぞ。スタックトレース見たら、A君の作ったプログラムだな。責任とって腹を斬れ！」と言われる光景を夢見てしまうのではなかろうか？ それで、とにかく通してしまおうとか？
もし、この推測が当たりなら、想像力は豊かに持っているってことになる。では、どうしてかくも想像力に乏しいプログラムを書けるんだろうか？
謎だ。
あるいは、「恥」ってやつの誤用勝手かも。例外で自分が担当したメソッドがスタックトレースを吐くのが恥ずかしいとか。例外を飛ばさない＝健康で素敵なプログラムとか。
でも、それは恥知らずな考え方だ。ゾンビになってスーパーをうろうろされたら、生きている人間に迷惑だ。さっさと往生するのが正しいありようだろう。でも、そのあたりのいさぎよさが欠けてるのかも。
アジャイルじゃないが例外喰らって死ぬ勇気を持って欲しいものだ。
しかし、なんで後先考えずに平気で飲み込むプログラムを書けるんだろうか？
謎だ。
ジェズイットを見習え |
前に聞いたことがありますが、その人のケースは「コンパイルが通らない」、「try-catchでくくらないといけないらしい」、「catchにはエラー処理を書かないといけないらしい」、「仕様書にエラ〜の場合なんて書いてないな〜、後で聞いてみよう」そのまま忘れる。というパターンでした。
やっぱり、「try-catchでくくらないと」を最初に教えるんじゃなくて、throws Exception と引数リストの後ろに書けばコンパイルは通るということを最初（あくまでも最初だけだろうな）に教えるほうがいいんじゃないかな。っていうか、そのへんは.NETの選択のほうが合理的だったと思う（というか、Javaの実情を見た上での決定だろうし）。
しかし例外の処理ってきちんとやろうとすると結構めんどくさいですよね。<br>ResultSetのcolseで検査例外飛ばなければまだましなんですが。<br>そのむかしif(conn!=null){conn.close()}と書こうとしてif(conn==null){conn.close()}とかいてしまいコネクションがダダもれしてたことがあります。<br>自分も含め馬鹿にはナマJDBCをいじらせないのが一番のような気がします。
書こうとして書き間違えるのは馬鹿とは言わないと思うけど（間違えるからこそ人間とか）、むしろリソースのクローズってのはアスペクトで解決すべき問題だと思う。<br>#ちょっとぶれたけど、本文は、throws Exception宣言無問題ですなコード規約上でのソースの話なところが悲しい。規約を守ればコンパイルエラーにはなりえないから、闇雲にcatchするという心理的な拘束があるのではないかという考察です。
「リソースのクローズってのはアスペクトで解決すべき問題」というのは非常に面白いです。もしかしたら、適切なアスペクトをきちんと作ることができれば、「例外」という仕組みもいらなくなるでしょうか。
なんとなく自分のまわりを見てるとコーダクラスって、やっかいな障害が起きた時の修正に突っ込まれることは少ない気がします。そんなレベルの人間を突っ込むと、かえって火に油を注ぐことになるし。なので、こんなコードを書いても自分自身が痛い目に会う事は意外と少ないかもしれません。
>自分自身が痛い目に会う事は意外と少ない<br>でしょ、だったらなんで意味無くcatchするのかと。<br>>適切なアスペクトをきちんと作ることができれば<br>JDBCのリソース解放について言えば、ResultSetや*StatementはConnectionのcommit/rollback/closeの時点で解放可能ですし、Connectionのcommit/rollback/closeはトランザクションの境界で判断できるので可能ですが、例外そのものは無理ではないかと。executeQueryで例外がスローされたらリソースの解放以前に、処理の続行不可能ということで（いや、queryはあまり重大な問題じゃなくて、update/deleteの失敗がシステム的には致命的な可能性が高いと思いますが）例外はやはり必要ではないでしょうか。<br>そうか、finallyは不要化できそうですね。
技術的素養がない人って「コケてくれることのありがたさ」が理解できなかったりするような、「止まってしまうより動き続けるほうがいい」みたいな、あるいは止まることを過剰に怖がるって言うか。