ああああああああ、 API は徹底的に攻めるプログラミングをしなきゃいけないってのがわかってんのかこの野郎。今日の仕事はとある EAI ツールの Java API を用いて適当なプロトを作り、そいつのプロセスを多重化したケースについていろいろ調べたりすることだったのだが。この API 、エラーが起きても例外を一切投げずにそのまま進行しやがる設計だった。だからエラーコードをどこかでキャッチせねばならないのだが、エラーコード一覧を見ても載ってないコードが返ってきやがる。複数のエラーが起きた場合、それらが全部加算されるようにしか思えねえ。
そして何に俺が躓いたかというと、複数のプロセスを立ち上げたときに一つだけ動作が出世コースを外れた力士のように重たくなる奴が出てきて、そいつの原因の究明だった。実はこれはトレースログのファイルをそのプロセスが排他的に使っていて他のプロセスはログを吐く必要がないので軽いだけ、というオチだったのだが。ログファイルを開けなかったらエラーを報告しろ! Java なんだから例外を投げろ! というかバックエンドの部分は Fail Fast で作れ! これは防衛的プログラミングでもなんでもない、寝小便したガキが布団とパジャマを隠しているだけだ。
そして最悪なのは、その API はドキュメントが Javadoc しかついてこない上にその Javadoc も最低限のことすら書かれていない。例えば最初は一時ファイルの競合でプロセスが正常に処理できないという問題もあったのだが、それについても何一つ書かれていなかった。一応それはプロセスユニークなファイル名を付けたりメモリ上に展開というメソッドがあったのだが、肝心要のトレースログには用意されてねえ。一応ログ用のディレクトリは指定できるので、要するに 1 プロセス 1 ディレクトリでやれと。そういうこともドキュメント化するべきだ (というか、ここ数日の俺の仕事は半分それだ) 。
話をライブラリの設計に戻すと、何度も書いている通りライブラリはエラーを握りつぶしてはいけない。出来ればデバッグモードなんかが仕込んであるととても良い。そしてエラーは出来るだけライブラリの使用者に見せ、そして出来るだけ即例外を投げるべきだ。例の API は設定ファイルのパスに存在しないパスや全然違うパスを渡しても例外になりやがらない。全部エラーコードで対応しろだと。まったくふざけた話だ。
今の環境で唯一の不満は、やっぱ日本語フォントなのだよな。こればっかりはいろいろ試してみないとわからんが、とにかく今の貧弱なフォントでは気持ち悪いし目にも悪い。