|
Chained Exception Facility |
||||||
例外の付け替え |
||||||
例外はいろいろなところで役にたっていると思います.デバッグのときにはもちろんですが、アプリケーションを使っているときにも例外に出くわすと思います.(本当は出くわしたくないとは思いますが...) ところで、例外を使っていると、例外を付け替えたいと思うことがないでしょうか。たとえば、よく使われるのは RMI で使われる RemoteException や、Servlet での ServletException があります。 RMI ではサーバでの例外をクライアントに伝えるには RemoteException しか使用することはできません。RMI でサーバのインタフェースを書くときに、すべてのメソッドに throws RemoteException と記述しますが、この RemoteException を利用してサーバ側での例外をクライアントに伝えるわけです. そうすると、こんなコードを書くことになります。
クライアント側では、この RemoteException を catch します。例外を catch した時の常套句として printStackTrace メソッドがあります。例外がどこの行で発生したかを示すためのメソッドです. RemoteException を catch して、printStackTrace メソッドを使用すると....
のように表示されます (行数などは適当に書いてます).しかし、ちょっと待ってください.これだと RemoteException が発生しているのは分かりますが、サーバのどこで RemoteException が発生したのか全然分からなくなってしまっています. ようするに、サーバ側でのもともとの例外の情報 (ここでは XXException の情報) がすっぽり抜け落ちてしまっているのです.これじゃ、デバッグするにも大変です。 そこで、RemoteException や ServletException では例外を new するときに、原因となった例外をコンストラクタの引数に与えることができます。
こうすることで、クライアントでもサーバ側のどこで例外が発生したかを知ることができます。
Caused by 以下の部分がサーバ側でのスタックトレースになります。 さて、RemtoeException や ServletException ではネストした例外を扱えることが分かりましたが、普通の例外でもこんなことをやってみたくないですが。 たとえば、あるアプリケーションで SomeApliIOException という例外を定義したとします.そして、アプリケーション中で発生した IOException などはそのまま使用するのではなく、この SomeApliIOException に付け替えて投げるようにするなんてことです. しかし、Java 2 SE, v1.4 までは、RemoteException などの特殊な例外以外は、例外の情報を引き継ぐことができませんでした。 この機能は地味ではあるのですが、結構使い出がありそうです.それでは以降の章で具体的な使い方について見ていきましょう。
|
自前の例外に原因をつける | |||||||
前振りは長いのですが、実際の使い方は簡単です.今回のサンプルは例外を起こすために書いてあるので、全然意味はないのですが、とりあえずコードがないと分かりにくいので。
TestException が例外クラスになります。 使い方は RemoteException の時と同じように、コンストラクタでネストする例外を指定します.ExceptionTest1 クラスで TestException を発生させている部分を次に示します.
InterruptedException を使ったのは特に意味はありません。プログラムとしても、3 行目で例外を throw して、4 行目で catch するのはまったく意味がないのですが、サンプルなのでゆるしてください. 見ていただきたいのは、5 行目です。コンストラクタの引数に原因となる例外を入れています.これを実行すると次のようになります。
ちゃんと TestException の原因となる InterruptedException のスタックトレースが (省略されてはいますが) 表示されています. さて、例外はどのように記述するのでしょうか。今までは、例外を派生するときには 2 つのコンストラクタを記述するだけでした (1 つはデフォルトコンストラクタなので、実質的には 1 つですが)。 新しい例外ではコンストラクタが 4 つになったので、これを記述するだけです.コンストラクタの中身も super を呼び出すだけです。
注意しなければいけないのは、原因となる例外は Exception クラスではなく、Throwable クラスであるということです。Exception クラスは Throwable クラスの派生クラスなのですが、この他に Throwable の派生クラスには Error クラスがあります。ネストさせるときには、どちらの障害も原因に指定できるようにするわけです.実際には Error をキャッチすることはないと思いますけど...
|
すでに用意されている例外に原因を付加する |
|||||||
自分で例外クラスを作った場合はいいのですが、もともとある IOException などの例外をネストさせるにはどうすればいいでしょうか。
とりあえず、同じように記述してみましょう。
しかし、これではコンパイルがとおりません。
IOException の JavaDoc を見てみると、確かにこんなコンストラクタはありません。さて、どうしましょう。 Exception の親クラスの Throwable の JavaDoc を見てみたら、ありました、こんなときに使えるメソッドが。initCause メソッドがそのメソッドです。 このメソッドはコンストラクタでネストする例外をしないときにしか使用できません。また、initCause をコールできるのは 1 度だけです.
例外を生成している部分を以下に示します.
5 行目で生成した例外に、6 行目の initCause で原因となる例外を指定しています.後は throw するだけです.
|
原因を探る |
||||||
例外の原因となった例外も含めたスタックトレースは表示できました。しかし、このスタックとレースの表示は原因の例外のスタックトレースの部分が省略されてしまっています。そこで、作ってみたのが次のサンプルです。
このサンプルでは原因を取り出して、その原因のスタックトレースを表示させています。
原因の例外を取得するには getCause メソッドを使用します。取得できたら、普通の例外と同じように扱うことができます。原因がないときには getCause メソッドの戻り値は null になります。
|
スタックトレースを使ってみる |
||||||||||
例外のスタックトレースはデバッグにはなくてはならない情報です。しかし、今まではスタックトレースは表示するだけで、プログラム中で使用することができませんでした。 J2SE, v1.4 ではスタックトレースを使用するために StackTraceElement というクラスが新たに追加されました。これを使用したサンプルが ExceptionTest4 です。
スタックトレースを取得するには Throwable クラスの getStackTrace メソッドを使用します。getStackTrace メソッドの戻り値は StackTraceElement オブジェクトの配列です。 このサンプルでは取得できたスタックトレースを単に出力しているだけです。実行結果は次のようになります。
このスタックトレースには原因となる例外のスタックトレースは含まれません。原因の例外のスタックトレースは、先ほどの getCause メソッドを使用して、原因例外を取得し、それに対し getStackTrace メソッドを行うことで取得できます。 StackTraceElemnt クラスには、スタックトレースのクラス名や行数などを取得するための getter メソッドが用意されています。それらを使用すれば、printStackTrace メソッドを使用したのと同じような表示を行うことも可能です。
ExceptionTest5 で使用したのは getClassName, getMethodName, getFileName, getLineNumber メソッドです。それぞれ、クラス名、メソッド名、ファイル名、例外の発生した行数を戻します。
さて、さっそく実行してみましょう。
printStackTrace を使用したときと、ほとんど同じように出力することができました。やっていないのはメッセージや原因例外があった場合についてです。この 2 つは例外クラスから情報をとるようにすれば可能です。
|
最後に |
||
かなり地味な機能ですが、こういう気のきいた機能が生産性の向上に非常に役立ったりします。少なくとも、アプリケーションに独自の例外クラスを作るのであれば、この機能を使用してインプリするようにしましょう。これだけで、デバッグがとても楽になると思いますよ。 今回使用したサンプルはここからダウンロードできます。 参考 URL
(Feb. 2002)
|
|