[´・[ェ]・] <もももっもっ

The Catcher in the Exception

Java, プログラム | 19:52 |

思った事をつらつら書くよ。あとタイトルに意味はないよ。

例外は何の為に存在するのか？

例外はクラスの操作方法を間違えた事をプログラマにお知らせするものです。コンパイルエラーみたいなもんだと思ってます。

例外の使い方

どのように例外を使用すべきか？

この問いに対して、ぼくは以下のようなコーディングルールを設ける事で例外の使用方法を明示する事にしました。

1. 非チェック例外を使おう
2. チェック例外は使用しないようにしよう
3. チェックメソッドを導入しよう
4. 出来うる限り例外の発生状況を書き出そう

非チェック例外を使おう

例外はクラスの操作を間違えた時に投げるべきです。

Iteratorを例にします。

Iteratorはnextメソッドで値を取得し、hasNextメソッドで次の値があるかどうかを確認するという使用方法があります。

これ以外の使用方法……例えば、hasNextメソッドで次の値があるかどうかを確認せずにnextメソッドを使う、という方法をとった場合、値が取得できなくなるとnextメソッドはNoSuchElementExceptionをスローします。

nextメソッドがNoSuchElementExceptionをスローするのは、クラスの使用方法を間違ったからです。決して値が取得できなくなった事をお知らせする為にスローされたのではありません。

例外はクラスの使い方を強制するものです。だから基本的に非チェック例外を使用し、クラスの使い方を間違ったら例外によりプログラムが強制的に停止するようにすべきです。

チェック例外は使用しないようにしよう

例外はコンパイルエラーと同等のものであると思っています。

コンパイルエラーを無視するとプログラムが動かないように、例外が発生するとプログラムが動かないような処置をすべきです。

そうなると、チェック例外というのは邪魔な存在です。例外によってプログラムを停止させる事を前提とした場合、try〜catch構文をわざわざ書くのは面倒です。しかも場合によってはプログラムを停止させずに続行するようなコードを書く場合もあるでしょう。

例外が発生するならプログラムを停止させるなら、チェック例外は使用する必要はないと思います。

チェックメソッドを導入しよう

クラスの内部状態をお知らせするチェックメソッドを作りましょう。

IteratorでいうところのhasNextメソッド、コレクションのisEmptyメソッドなどが該当するでしょう。

例外に頼るコードは、チェックメソッドを使って置き換えましょう。

もちろん、クラスの実装がバレるようなチェックメソッドを作れというわけではありません。クラスを外側から見た時に必要となるチェックメソッドを実装すべきです。

出来うる限り例外の発生状況を書き出そう

例外をコンパイルエラーのように扱うのなら、例外が何故発生したのかをなるべく詳しくプログラマに知らせるべきです。

コンパイルエラーの状態が詳しく表示されないコンパイラが嫌がられるように、例外も発生状況が詳しく書かれていないのは不都合です。

具体的には、例外が発生した時のフィールドの値を例外のインスタンスに格納しておくと良いと思います。

もちろん、これも不用意に内部実装をさらけ出す必要はありません。

こんぷーた

メモ, こんぷーた, 暴論 | 01:59 |

• スケジュールのないこんぷーたを作ろう
• かっこいいこんぷーたを作ろう
• 出来うる限り小さなこんぷーたを作ろう
• 成果を求めないこんぷーたを作ろう

顧客がいないこんぷーたを作ろう(2010/01/28)

ニホンのコンピュータ系がなんで重労働なのかを考えた時、「お客様第一主義」が思い浮かぶ。

お客様第一主義はこの国の商業の基本みたいなものになってて、どんなに低級なサービスにおいてもその主義を掲げようとする。

これが高級ホテルや高級百貨店なら、お客様第一主義を掲げるのは分かる。高級なものとは、高額である代わりに客が満足行くサービスを提供するから高級なのである。その前提があってこそのお客様第一主義であると私は考える。

しかしこの国では高級とも呼べないような場所でさえお客様第一主義を要求する。

例えば、コンビニ。店員の態度が悪い！　と怒鳴ったりクレームを付ける輩がいる。たかが数百円の買い物で、店員を奴隷に出来ると勘違いしている。

ニホンは客の立場だと間違いなく天国といえる。お金がなくてもおもてなしの行き届いたサービスが受けられる。ところが、これが従業員の立場となると話は別だ。とたんに地獄になる。

ニホンジンの気質なのかどうかは知らないが、とにかく小さな小さな事で従業員にクレームを付ける。道理の通らない無理を通そうとするクレームを付ける。

この国のおもてなしの精神というのは善意で行われているはずなのに、今では強制的な義務にまで昇華し、道理やルールをねじ曲げてまで「お客さまは神さまだ！」と言わなければならない。

これがコンピュータ業界になるとさらに地獄を見る。

例えば、ソフトウェアの開発を依頼された場合、開発会社はソフトウェア開発の後に「テスト」を行なう。テストとはソフトウェアが仕様通りに動くかどうかをチェックする工程である。

テストは小さな単位のプログラムの場合、コンピュータを使って自動化できる(もちろん、自動化を行なう為のテストコードは自分で書かなければならない)。小さな単位と言っても、危惧すべき事は多い。

入力したデータが正しいものか、不正なものか。入力データが複数ある場合、いくつかのデータが入力されてなかったらどうなるか。入力データが不正だった場合のエラーの返し方はどうするか。入力データを元に出力するデータは、正しいものか。そもそもアルゴリズムが正しいか。

これ以外にも、もっと詳細を考えるとチェックしなければならない項目は増える。データの入力が一つ増えるだけで、この項目が倍になる可能性がある。

これはあくまで単独ではソフトウェアとも呼べないような小さなプログラムの話だ。

小さなプログラムが集まってソフトウェアとなった時、またテストを行なう。小さなプログラムと小さなプログラムを合体ささせた時、場合によってはバグが生まれる可能性があるからだ。今度のテストは完全なる力技だ。

ぼくが勤怠を入力するソフトウェアをテストした時の話だが、AM08:00〜AM08:30から入力を始め、AM05:00まで延々と手で入力を行なうのだ。そしてそれが終わったら、AM08:30からのテストを延々と入力し続ける。これを一日中やり続けるのだ。結果、三日間はこの作業を続けさせられた。これが納期のない、比較的緩やかな時間を設けられたから良かったものの、短納期でこの作業を行おうとした場合、ソフトウェア開発会社の従業員は、寝ずの作業を強いられる事になる。そして酒の席で自分の体験談をさも誇りであるかのように自慢するのだ。

何が問題か。

ソフトウェア開発を行なう会社は、お客様のクレームを恐れているから力技でもいいからテストを行おうとするのである。

お客様はバグのない完璧なソフトウェアを求めようとする。しかしそれは夢である。テストで発見できなかったバグは、バグとしてそのままお客様に納品されるのだ。

そして客はバグが発生した場合、それを「クレーム」としてソフトウェア開発会社に提出する。そして短納期でバグを発見し、抹消せよと命じるのだ。そしてまた、会社の窓から灯が消える事がなくなる。

お客様が無理を言う場合、その分何らかの見返り(それはお金だったり、次の開発に関する契約だったりする)を儲けるソフトウェア開発会社もある。ただ、次の開発の契約を見返りにしようとする会社をぼくは好かない。結局次の開発も契約を見返りに社員に無理をさせる可能性が高いからだ。お客様は前の開発で行った無理を普通であると勘違いして、次の開発スケジュールも無理を前提として作成している可能性は、とても高い。

だから、お客様のいないコンピュータを作るべきである。

そうしない限り、従業員に常に無理を強いる仕組みが出来てしまう。マネジメントが上手いヒトが権限を持っている会社なら無理を回避する事は十分に可能だが、そうでない場合、従業員は地獄を見る。これはきっとニホンジンである限り発生しつづけるだろうと、ぼくは思っている。

こんぷーた

メモ, こんぷーた | 01:59 |

• 顧客がいないこんぷーたを作ろう(2010/01/28)
• スケジュールのないこんぷーたを作ろう
• かっこいいこんぷーたを作ろう
• 出来うる限り小さなこんぷーたを作ろう

言いたい事を言いまくるおれ

Twitter | 05:58 |

データをJDOに格納・更新・削除する場合について

JDO, GAE, メモ | 00:49 |

Insertは

Model model = new Model();

model.setXxx(...);

...

tx.begin();

pm.makePersistent(model);

tx.commit();

Updateは

tx.begin();

Model model = pm.getObjectById(Model.class, id);

model.setXxx(...);

tx.commit();

Deleteは

tx.begin();

Model model = pm.getObjectById(Model.class, id);

pm.deletePersistent(model);

tx.commit();

で処理するのは、JDOとして標準的なやり方です。

makePersistent()は、newしたモデルをpersistentするときか

detachedなモデルをpersistent状態にするときに使うもので、

それ以外で使うものではありません。

getObjectById()で取得したモデルはpersistentな状態です。

GAE/JavaのdeletePersistentで生じるエラーへの対処 - Google-App-Engine-Japan | Google グループ