例外

CORBA には次の 2 種類の例外があります。OMG で完全に規定された標準システム例外と、アプリケーションプログラマが定義するユーザー例外の 2 つです。CORBA の例外は Java の例外オブジェクトとは多少異なりますが、その違いの大部分は IDL から Java へのマッピング時に解決されます。

ここでは、次の項目について説明します。

CORBA の例外と Java の例外の違い
システム例外
ユーザー例外
マイナーコードの意味

CORBA の例外と Java の例外の違い

IDL で例外を指定するには、インタフェースの設計者はキーワード raises を使用します。これは、Java で throws を指定するのと同様です。IDL でこの例外キーワードを使用する場合は、ユーザー定義例外を作成することになります。標準システム例外では、このような指定をする必要はなく、また、このような指定をすることはできません。

システム例外

CORBA では、一連の標準システム例外が定義されています。標準システム例外は、次のようなシステム関連のエラー状態の発生を知らせるため、一般に ORB ライブラリによって生成されます。

リソースの不足や起動の失敗など、サーバー側のシステム例外。
オブジェクトとの通信が切断された、ホストが停止している、ORB デーモン (orbd) と接続できないなど、通信関連のシステム例外。
オペランドの型が無効、要求が送られる前または結果が返されたあとに何らかの問題が発生したなど、クライアント側のシステム例外。

システム例外は、呼び出されたすべての IDL オペレーションに対してスローされる可能性があります。インタフェースの設計者は、インタフェース内のオペレーションでシステム例外をスローできるような仕様にする必要はありません。この処理は自動で行われます。

オペレーションの実装がどれほど単純であったとしても、別のプロセス (多くが別のマシン上のプロセス) であるクライアントからオペレーション呼び出しが行われることにより、あらゆるエラーが発生する可能性があるため、この仕様は妥当です。

したがって、CORBA クライアントでは、CORBA のシステム例外を常にキャッチするようにすべきです。また、CORBA のシステム例外は java.lang.RuntimeException の下位クラスになるため、キャッチすべきシステム例外の通知を Java コンパイラに任せることはできません。

システム例外の構造

CORBA のシステム例外は、すべて次のような同じ構造をしています。

exception <SystemExceptionName> { // descriptive of error
    unsigned long minor;          // more detail about error
    CompletionStatus completed;   // yes, no, maybe
}

システム例外は、java.lang.RuntimeException から org.omg.CORBA.SystemException までのクラスのサブタイプです。

java.lang.Exception
- java.lang.RuntimeException
  - org.omg.CORBA.SystemException
    - BAD_PARAM
    - //etc.

マイナーコード

CORBA のすべてのシステム例外には、例外発生の原因となったエラーに関する付加的情報を提供するマイナーコードフィールドが設けられています。マイナーコードの意味は OMG では規定されておらず、各 ORB ベンダーが、その実装ごとに適切なマイナーコードを規定することになっています。Java ORB によってスローされるマイナーコードの意味については、「マイナーコードの意味」を参照してください。

完了ステータス

CORBA のすべてのシステム例外には、例外をスローしたオペレーションのステータスを表す完了ステータスフィールドがあります。完了状態コードには、次の 3 つがあります。

COMPLETED_YES: オブジェクトの実装は、例外が起こる前に処理を完了した。
COMPLETED_NO: オブジェクトの実装は、例外が起こる前に呼び出されなかった。
COMPLETED_MAYBE: 呼び出しのステータスが不明。

ユーザー例外

CORBA のユーザー例外は、java.lang.Exception から org.omg.CORBA.UserException までのクラスのサブタイプです。

java.lang.Exception
- org.omg.CORBA.UserException
  - Stocks.BadSymbol
  - //etc.

各ユーザー定義例外は、生成された Java 例外クラスの IDL の結果の中で規定します。ユーザー定義例外は、すべてプログラマが定義し、実装します。

マイナーコードの意味

すべてのシステム例外には、CORBA ベンダーが例外発生の原因に関する付加的情報を提供できるように、minor というフィールドが設けられています。OMG の標準マイナーコード例外 (OMGVMCID) のリストについては、Object Management Group の Web サイトを参照してください。

よく遭遇する Sun のマイナーコード例外には、次のようなものがあります。

COMM_FAILURE/201。vmcid:SUN minor code:201 は、「CONNECT_FAILURE」を意味します。これは、java.net.SocketException が原因で生じることがあり、通常は BindException、ConnectException、または NoRouteToHostException のいずれかです。
次のような点を確認する必要があります。
- ネームサービスは実行されているか。そうでない場合は、ドキュメント「ネームサービスの起動と停止」の説明に従って、ORBD ネームサービスを開始します。
- ネームサービスに対して -ORBInitialHost および -ORBInitialPort の値が正しく設定されていますか。どのように設定するべきかわからない場合は、ドキュメント「ネームサービスの起動と停止」を参照してください。
- クライアントアプリケーションとサーバーアプリケーションは、ネームサービスが実行されているポート番号 (必要な場合は、さらにマシン名) を認識しているか。これを行う方法については、「ネームサービスの起動と停止」を参照してください。
COMM_FAILURE/208。vmcid:SUN minor code:208 は、「CONNECTION ABORT」を意味し、これは一般に、接続が切れたことを表します。
COMM_FAILURE/209。vmcid:SUN minor code:209 は「CREATE_LISTENER_FAILED:Unable to create the listener thread on the specific port. Either the post is taken or there was an error creating the daemon thread」を意味します。これは一般に、ネームサービスを実行しようとしたポートが別のプロセスによって使用中であることを示しています。Solaris 上で実行している場合には、このポートで別のプロセスが実行中かどうかを調べるために、端末プロンプトで次のコマンドを実行します。
```
netstat | grep port_number
```
OBJECT_NOT_EXIST/204。vmcid:SUN minor code:204 は、「SERVANT_NOT_FOUND」を意味します。これがスローされる唯一の場所は、corba.INSSubcontract.getINSReference です。
MARSHAL/217。vmcid:SUN minor code:217 は、クライアントが GIOP 1.0 で wchar か wstring のいずれかを送信しようとしたことを意味し、これは仕様で許可されていません。
MARSHAL/202。vmcid:SUN minor code:202 は、org.omg.CORBA.Object から派生したオブジェクトを整列化しようとしているが、その特定のインスタンスが ORB に接続されていないことを意味します。POA を使用する場合は、まずオブジェクトを POA に登録する必要があります。オブジェクトを POA に登録する方法の詳細については、POA のドキュメントまたはチュートリアルを参照してください。
BAD_PARAM/201。vmcid:SUN minor code:201 は、「NULL_PARAM」を意味します。この例外は、多くの場合、write_string や write_octet_array などの write メソッドに Java null が渡されたために発生します。Java メソッドの結果として Java null を返すことはできません。
org.omg.CORBA.INTERNAL。vmcid:SUN minor code:208 は Unable to determine local hostname using InetAddress.getLocalHost().getHostName() を意味します。
ORB は、InetAddress.getLocalHost().getHostName() を使用して、参照の検索やバインドのためにネームサービスへの参照を作成します。また、サーバー側で InetAddress.getLocalHost().getHostName() を使用して、ドット区切り 10 進数とポートの組み合わせではなく、サーバーの名前とポートを含んだリモートオブジェクト参照 (つまり IOR) を作成します。

getHostName の呼び出しを回避するために、次のようなプロパティーを設定できます (設定方法がわからない場合は、「ネームサービスの起動と停止」を参照)。
- ORB がサーバーとして機能している場合は、com.sun.CORBA.ORBServerHost にサーバーの DNS 名またはドット区切り 10 進数アドレスを設定します。
- com.sun.CORBA.ORBInitialHost に、ネームサーバーの DNS 名またはドット区切り 10 進数アドレスを設定します。
注: これらのプロパティーは独自のもので、削除または変更されることがあります。

上記の説明では不十分な場合、または上記以外の Sun マイナーコードに遭遇した場合には、Oracle Forum Home の開発者フォーラムにメッセージを投稿してください。

マイナーコードの意味について情報を求める場合には、次の情報をお知らせください。

クライアントおよびサーバーを実行しているプラットフォーム (Solaris、Linux、Win32 など)
使用している Java SE のバージョン (1.5.0_01 など)
スタックトレース全体
異なるベンダーのネームサービスまたは ORB を使用している場合は、製品のベンダーとバージョンに関する情報。

連絡先