今回は軽いお話です。

開発をしていると、「ん？この和訳はどうか・・・」と思わされることが度々ありますよね。どなたも経験をお持ちだと思います。今日はその中で私が普段関わっている業務の中で度々出くわす2つ、大きいものと小さいものをご紹介したいと思います。

■ Java の 「チェック済み例外」
「チェック例外」、「検査例外」と訳している例もあるようですが、これらはまだマシかな？苦心の跡かな？と思います。英語では、”checked exception” ですね。

まあこれ、英語の名前付ける時も苦労したんだろうとは思いますが、まずこれを見て意味が分かる人は居ないと思います。

Exception クラスから派生した例外を指してこのように呼称しますが、言語仕様に沿って命名するなら「キャッチ必須例外」でしょうか。センス無いですか？すみません・・・。

一方で、catch が必要ではない例外が「ランタイム例外」です。なんか命名にも対称性が無いというか・・・。

Java 以前の言語ではそもそも例外というのはランタイム例外の事をさし、catch を強制するような事はありませんでした。なのでこちらの方が他の言語では「普通の例外」？なわけです。

この例外周りの言語仕様自体が議論の的になっているのは以前私も個人ブログで指摘した通りです。

http://www.ibm.com/developerworks/jp/java/library/j-jtp05254/
などは、2004年の記事ですが、よくまとまっています。
まとめると以下のような感じでしょうか。
—–
Bruce Eckel
タカ派。 Thinking in Java の著者。
「チェック済み例外」否定派。いかなる場合でもチェック
なし例外を使用するべき。
C++ にはチェックなし例外しか存在しない。「例外」を
「例外的」な場合にのみ使用すべき。

Rod Johnson
J2EE Design and Development 著者。
二次的な戻りコードのみにチェック済み例外を使用すべき。
戻りコードの代替としてチェック例外を使用する立場。

Josh Bloch
Effective Java の著者。見解はもっとも Sun 寄り。
—–

この「例外」を例外？以外の状況で使えるようにしたのが議論のタネになってしまっている訳です。「邪道だろう」と。

Java が原文ですら、「checked exception」というよく意味の分からない名前にせざるを得なかったのは、このようなそもそも用途が微妙な言語仕様を現場での利便性優先で採用したからだと思われます。このような理想に走らない利便性優先の言語仕様は Java では散見されますが、まあ、私は好きですね。手になじむデイリーユースのツール、という印象。

話が脱線したので元に戻しますが、せめて「検査必須例外」くらいの和訳にならんかなと思う点です。

■ JMeter の「定数スループットタイマー」

「また JMeter か、お前どれだけ JMeter 好きなんだ」と言われそうですが、好きなんだから仕方ないじゃないですか。

「定数スループットタイマー」は、要するに一定のスピードにリクエストの量を制限して発行するための機能です。

だとして、「定数スループットタイマー」っていわれて、「ああなるほど」って思えるものなのでしょうか？私には意味が分かりませんでした。

原文ではどういう名前かというと、「Constant Throughput Timer」なんですよね。「コンスタントスループットタイマー」

「コンスタントなスループットを得るためのタイマーなんだな」って逆に大体の人が分かるのでは無いかと思うのですが、私の気のせいでしょうか？

「コンスタント」は一般的には「定数」と訳すことが多いのかもしれませんが、ここはあえて訳さずそのままにしておいてほしかったなぁと思ったものでした。

この手の話ってみなさんそれぞれお持ちだと思うのですが、割ともりあがる話題ですよね。今日はこの辺で。ご意見は blog@keis-software.com まで。

ではでは。