このアーカイブは同期化されません。 mixi の日記が更新されても、このアーカイブには反映されません。
今日は例外処理について考えてみよう。
ユーザと対話的に処理を行うプログラムと違い、
自動化プログラムは、例外処理に厳格である必要がある。
例外処理は、トラップ（catch）するのも大切だが、
必要な所で例外を発生（throw new）させるのも大切である。
例えば、HTTP アクセスを行う場合、
ネットワークの障害があった場合、
通信エラーが発生することがある。
また、サーバの処理能力やトラブルによっては、
必要なリソースが得られなかった場合、
エラーを示すステータスコードが返る場合がある。
XMLHttpRequest においては、前者の通信エラーの場合、
Error クラスの例外が投げられるが、
後者のサーバエラーの場合は、特に例外は起きない。
MixiSession のようなクラスの場合、
正常にデータが取得できなかった場合は失敗だ。
また、メールアドレスやパスワードが違う場合、
mixi はログイン失敗の HTML を返す。
これは、HTTP のレイヤでは成功とみなされるが、
MixiSession では例外としなければならない。
さて、JavaScript には、全ての例外のベースとなる、
Error 型オブジェクト（Error コンストラクタ）が存在する。
また、NativeError と総称される、
SyntaxError 型や TypeError 型など、
Error から派生した型も存在し、
よりエラーの原因に即したオブジェクトが定義されている。
では、MixiError クラスを作ってみよう。
JavaScript で Error 型を定義するためには、
以下の条件を満たす必要がある。
・コンストラクタは message の引数を 1 つ取り、
undefined でなければ、新しいインスタンスの
message プロパティに文字列として格納する。
・プロトタイプは name プロパティを持ち、
型の名前の文字列を持つ。（この場合、"MixiError"）
・プロトタイプは message プロパティを持ち、
値は実装依存の文字列。
・プロトタイプは toString プロパティを持ち、
値は引数のない関数であり、戻り値は実装依存の文字列。
・プロトタイプは constructor プロパティを持ち、
値はコンストラクタへの参照。
上記は、仕様である ECMA-262 3rd Edition に記載がある、
Error オブジェクトの要件である。
Error はユーザの例外処理コードで参照されるため、
独自の Error 型を作成する場合、
Error 型と同じように利用できることが好ましいのだ。
因みに、最後の要件である constructor プロパティは、
あらゆる型について実装することが好ましい。
では、作ってみよう。
========== MixiError.js ==========
// MixiError コンストラクタ
function MixiError(message) {
if (message !== undefined) {
this.message = String(message);
}
}
// プロトタイプ
MixiError.prototype.name = "MixiError";
MixiError.prototype.message = "";
MixiError.prototype.toString = function () {
return "[object " + this.name + "]";
};
========== end of MixiError.js ==========
コンストラクタに作成される prototype プロパティは、
既定で constructor プロパティを持ち、
そこにはコンストラクタが設定されているので、
以下のようにコードで明示する必要はない。
MixiError.prototype.constructor = MixiError;
このように型を定義しておけば、
Error と同じように使うことができる。
try {
throw new MixiError("エラー内容");
} catch (ex) {
WScript.Echo(ex.name + ": " + ex.message);
}