## 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, which the OMG initially defined to be opaque. In later CORBA specifications explicit values have been defined for the minor field, but only for a handfull of the exceptions, to enable a more exact description. Currently, Orber still uses the old settings, which is why the minor field should not be taken into consideration for exceptions raised by Orber.

#### 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-2002 Ericsson Utvecklings AB