例外

CORBAには次の2種類の例外があります。OMGで完全に規定された標準システム例外と、アプリケーション・プログラマが定義するユーザー例外です。 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のマニュアル・ページ(Solaris、Linux、Mac OS XまたはWindows)の説明に従って、ORBDネーム・サービスを開始します。
- ネーム・サービスに対して-ORBInitialHostおよび-ORBInitialPortの値が正しく設定されていますか。どのように設定するべきかわからない場合は、orbdのマニュアル・ページ(Solaris、Linux、Mac OS XまたはWindows)を参照してください。
- クライアント・アプリケーションとサーバー・アプリケーションは、ネーム・サービスが実行されているポート番号(必要な場合は、さらにマシン名)を認識しているか。これを行う方法については、orbdのマニュアル・ページ(Solaris、Linux、Mac OS Xまたは)を参照してください。
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の呼出しを回避するために、次のようなプロパティを設定できます(設定方法がわからない場合は、orbdのマニュアル・ページ[Solaris、Linux、Mac OS XまたはWindows]を参照)。
- ORBがサーバーとして機能している場合は、com.sun.CORBA.ORBServerHostにサーバーのDNS名またはドット区切り10進数アドレスを設定します。
- com.sun.CORBA.ORBInitialHostに、ネーム・サーバーのDNS名またはドット区切り10進数アドレスを設定します。
ノート: これらのプロパティは独自のもので、削除または変更されることがあります。

連絡先