CORBA System and User Defined Exceptions

## 11 CORBA System and User Defined Exceptions

### 11.1 System Exceptions

`Orber`, or any other `ORB`, may raise a `System Exceptions`. These exceptions contain status- and minor-fields and may not appear in the operation's raises exception IDL-definition.

#### 11.1.1 Status Field

The status field indicates if the request was completed or not and will be assigned one of the following erlang atoms:

Table 1: System Exceptions Status
Status | Description
'COMPLETED_YES' | The operation was invoked on the target object but an error occured after the object replied. This occur, for example, if a server replies but Orber is not able to marshal and send the reply to the client ORB.
'COMPLETED_NO' | Orber failed to invoke the operation on the target object. This occur, for example, if the object no longer exists.
'COMPLETED_MAYBE' | Orber invoked the operation on the target object but an error occured and it is impossible to decide if the request really reached the object or not.

#### 11.1.2 Minor Field

The minor field contains an integer (VMCID), which is related to a more specific reason why an invocation failed. The function `orber:exception_info/1` can be used to map the minor code to a string. Note, for VMCID:s not assigned by the OMG or Orber, the documentation for that particular ORB must be consulted.

#### 11.1.3 Supported System Exceptions

The OMG CORBA specification defines the following exceptions:

- 'BAD_CONTEXT' - if a request does not containt a correct context this exception is raised.
- 'BAD_INV_ORDER' - this exception indicates that operations has been invoked operations in the wrong order, which would cause, for example, a dead-lock.
- 'BAD_OPERATION' - raised if the target object exists, but that the invoked operation is not supported.
- 'BAD_PARAM' - is thrown if, for example, a parameter is out of range or otherwise considered illegal.
- 'BAD_TYPECODE' - if illegal type code is passed, for example, encapsulated in an any data type the `'BAD_TYPECODE'` exception will be raised.
- 'BAD_QOS' - raised whenever an object cannot support the required quality of service.
- 'CODESET_INCOMPATIBLE' - raised if two ORB's cannot communicate due to different representation of, for example, `char` and/or `wchar`.
- 'COMM_FAILURE' - raised if an ORB is unable to setup communication or it is lost while an operation is in progress.
- 'DATA_CONVERSION' - raised if an ORB cannot convert data received to the native representation. See also the `'CODESET_INCOMPATIBLE'` exception.
- 'FREE_MEM' - the ORB failed to free dynamic memory and failed.
- 'IMP_LIMIT' - an implementation limit was exceeded in the ORB at run time. A object factory may, for example, limit the number of object clients are allowed to create.
- 'INTERNAL' - an internal failure occured in an ORB, which is unrecognized. You may consider contacting the ORB provider's support.
- 'INTF_REPOS' - the ORB was not able to reach the interface repository, or some other failure relating to the interface repository is detected.
- 'INITIALIZE' - the ORB initialization failed due to, for example, network or configuration error.
- 'INVALID_TRANSACTION' - is raised if the request carried an invalid transaction context.
- 'INV_FLAG' - an invalid flag was passed to an operation, which caused, for example, a connection to be closed.
- 'INV_IDENT' - this exception indicates that an IDL identifier is incorrect.
- 'INV_OBJREF' - this exception is raised if an objet reference is malformed or a nil reference (see also corba:create_nil_objref/0).
- 'INV_POLICY' - the invocation cannot be made due to an incompatibility between policy overrides that apply to the particular invocation.
- 'MARSHAL' - this exception may be raised by the client- or server-side when either ORB is unable to marshal/unmarshal requests or replies.
- 'NO_IMPLEMENT' - if the operation exists but no implementation exists, this exception is raised.
- 'NO_MEMORY' - the ORB has run out of memory.
- 'NO_PERMISSION' - the caller has insufficient privileges, such as, for example, bad `SSL` certificate.
- 'NO_RESOURCES' - a general platform resource limit exceeded.
- 'NO_RESPONSE' - no response available of a deferred synchronous request.
- 'OBJ_ADAPTER' - indicates administrative mismatch; the object adapter is not able to associate an object with the implementation repository.
- 'OBJECT_NOT_EXIST' - the object have been disposed or terminated; clients should remove all copies of the object reference and initiate desired recovery process.
- 'PERSIST_STORE' - the ORB was not able to establish a connection to its persistent storage or data contained in the the storage is corrupted.
- 'REBIND' - a request resulted in, for example, a `'LOCATION_FORWARD'` message; if the policies are incompatible this exception is raised.
- 'TIMEOUT' - raised if a request fail to complete within the given time-limit.
- 'TRANSACTION_MODE' - a transaction policy mismatch detected.
- 'TRANSACTION_REQUIRED' - a transaction is required for the invoked operation but the request contained no transaction context.
- 'TRANSACTION_ROLLEDBACK' - the transaction associated with the request has already been rolled back or will be.
- 'TRANSACTION_UNAVAILABLE' - no transaction context can be supplied since the ORB is unable to contact the Transaction Service.
- 'TRANSIENT' - the ORB could not determine the current status of an object since it could not be reached. The error may be temporary.
- 'UNKNOWN' - is thrown if an implementation throws a non-CORBA, or unrecognized, exception.

### 11.2 User Defined Exceptions

User exceptions is defined in IDL-files and is listed in operation's raises exception listing. For example, if we have the following IDL code:

    module MyModule {

      exception MyException {};
      exception MyExceptionMsg { string ExtraInfo; };

      interface MyInterface {

        void foo()
          raises(MyException);

        void bar()
          raises(MyException, MyExceptionMsg);

        void baz();
      };
    };

### 11.3 Throwing Exceptions

To be able to raise `MyException` or `MyExceptionMsg` exceptions, the generated `MyModule.hrl` must be included, and typical usage is:

    -module('MyModule_MyInterface_impl').
    -include("MyModule.hrl").

    bar(State) ->
        case TestingSomething of
            ok ->
               {reply, ok, State};
            {error, Reason} when list(Reason) ->
               corba:raise(#'MyModule_MyExceptionMsg'{'ExtraInfo' = Reason});
            error ->
               corba:raise(#'MyModule_MyException'{})
        end.

### 11.4 Catching Exceptions

Depending on which operation we invoke we must be able to handle:

- foo - `MyException` or a system exception.
- bar - `MyException`, `MyExceptionMsg` or a system exception.
- baz - a system exception.

Catching and matching exceptions can bee done in different ways:

        case catch 'MyModule_MyInterface':bar(MIReference) of
            ok ->
               %% The operation raised no exception.
               ok;
            {'EXCEPTION', #'MyModule_MyExceptionMsg'{'ExtraInfo' = Reason}} ->
               %% If we want to log the Reason we must extract 'ExtraInfo'.
               error_logger:error_msg("Operation 'bar' raised: ~p~n", [Reason]),
               ... do something ...;
            {'EXCEPTION', E} when record(E, 'OBJECT_NOT_EXIST') ->
               ... do something ...;
            {'EXCEPTION', E} ->
               ... do something ...
        end.

Copyright © 1991-2006 Ericsson AB