規約の裏を深読みする！

ここまでは例外の言語仕様の中からいくつかをピックアップしてその内容を説明してきました。最後に言語仕様で決められているいくつかの定義について、その裏側に隠された意図を探っていきたいと思います。

なぜオーバーライド時に例外を追加できないのか

オーバーライドとはサブクラスでメソッドの上書きを行うことです。言語仕様の中にはオーバーライド時のルールが記載されています。

The throws clause of an overriding method may not specify that this method will result in throwing any checked exception which the overridden method is not permitted, by its throws clause, to throw.

（訳：オーバーライドを行うメソッドのthrows節では、このメソッドによってオーバーライドされるメソッドのthrows節がスローすることを許していないチェック例外をスローするような指定は行えない）。

簡単にいえばオーバーライド時にthrowsに指定する例外クラスを変更することはできないといっているのですが、その理由については記載されていません。筆者はその理由としてポリモーフィズムとの関連が強いと考えています（図参照）。

クラスBおよびCはインターフェイスAを継承しtestメソッドを実装しています。変数aの実体がクラスBもしくはクラスCということを意識せずにtestメソッドを実行し、実際動作するのはそのオブジェクトのtestメソッドです。これがポリモーフィズムです。ここで仮にクラスBのtestメソッドのthrowsにPrintExceptionを追加するとしましょう。するとtestメソッド実行時のcatch節はどうなるでしょうか？

変数aがクラスCなら今のままですが、クラスBなら新たなcatch節が必要になります。これではポリモーフィズムの利点が得られないし、そもそもJavaではこのようなことは許されません。

これが筆者の考えた規約の裏にある理由です。このように規約と規約が守りあって仕様を成しているのです。

RuntimeException系の独自例外はなしか

既存の例外クラスを拡張して独自の例外クラスを作成することができます。言語仕様には推奨という形でガイドラインが記載されています。

To take advantage of the Java platform's compile-time checking for exception handlers, it is typical to define most new exception classes as checked exception classes, specifically as subclasses of Exception that are not subclasses of RuntimeException.

（訳：Javaプラットフォームが行う、例外ハンドラに対するコンパイル時チェックの利点を享受するため、新たな例外クラスはチェック例外クラスとして、特にRuntimeExceptionのサブクラスでないExceptionのサブクラスとして定義するのが一般的である）。

恐らく独自の例外クラスを作成したことのある方は、ここに記載されている通りにExceptionクラスを継承して作成していることでしょう。かくいう筆者もそうします。ただここでそのまま言語仕様通りに常にExceptionクラスを継承すればいいのでしょうか？ RuntimeExceptionクラスを継承した独自例外はないのでしょうか？ そう考えた場合、筆者はアリと考えました。

それはRuntimeExceptionのcatch不要の性質を利用するのです。フレームワークもしくは共通部品を提供するような立場で、実際にそれらを使ってもらう実装者に意図しない使われ方をした場合、RuntimeException系の例外をスローするというものです。もちろん開発中に限定して実装するのですが、この利点としては実装者にcatchを強制させずに誤っていることを通知できることです。その例外をスローする必要性がなくなったときに除去したとしても、実装側には何らインパクトはありません。

筆者も含めただ何となくExceptionクラスを継承するのが通例だからそうしていたという方も多いでしょう。今後はJavaの言語仕様で推奨されているからといってみてはいかがでしょうか。また、そのときに理由もいえるとなおプロらしいと思いませんか？

最後に参考として言語仕様とJDKのそれぞれの版（バージョン）の相関図を示します。現在自分が読むべき言語仕様の参考にしてください（図参照）。

最後に

3回を通してJavaの言語仕様を詳しくみてきましたが、いかがでしたでしょうか。正直筆者たちも今回のお話があるまでは、詳しく言語仕様を読むことはありませんでした。つまり言語仕様は実は知らなくても困るものではないのです。なぜなら、これまで解説してきた内容の表層部分、つまり通例と呼ばれるものは、書籍なりネットなりで皆さんもいろいろと知識を得られるからです。

しかし、それらの情報の元を突き詰めていくとすべては言語仕様にあるのです。今度疑問があったとき、検索エンジンではなく言語仕様から疑問を解消してみてはいかがでしょうか。なぜなら言語仕様には、そのプログラミング言語のすべてが書かれているのですから。 タイトルへ戻る