Erlang -- CORBA System and User Defined Exceptions

orber

User's Guide

Version 3.8.3

- User's Guide
- Reference Manual
- Release Notes
- PDF
- Top

- Expand All
- Contract All

### Chapters

- The Orber Application
  - Top of chapter
  - Content Overview
  - Brief Description of the User's Guide
- Introduction to Orber
  - Top of chapter
  - Overview
- The Orber Application
  - Top of chapter
  - ORB Kernel and IIOP
  - The Object Request Broker (ORB)
  - Internet Inter-Object Protocol (IIOP)
- Interface Repository
  - Top of chapter
  - Interface Repository(IFR)
- Installing Orber
  - Top of chapter
  - Installation Process
  - Configuration
  - Firewall Configuration
  - Interface Configuration
- OMG IDL to Erlang Mapping
  - Top of chapter
  - OMG IDL to Erlang Mapping - Overview
  - OMG IDL Mapping Elements
  - Getting Started
  - Basic OMG IDL Types
  - Template OMG IDL Types and Complex Declarators
  - Constructed OMG IDL Types
  - Scoped Names and Generated Files
  - Typecode, Identity and Name Access Functions
  - References to Constants
  - References to Objects Defined in OMG IDL
  - Exceptions
  - Access to Attributes
  - Invocations of Operations
  - Implementing the DB Application
  - Reserved Compiler Names and Keywords
  - Type Code Representation
- CosNaming Service
  - Top of chapter
  - Overview of the CosNaming Service
  - The Basic Use-cases of the Naming Service
  - Interoperable Naming Service
- How to use security in Orber
  - Top of chapter
  - Security in Orber
- Orber Stubs/Skeletons
  - Top of chapter
  - Orber Stubs and Skeletons Description
- CORBA System and User Defined Exceptions
  - Top of chapter
  - System Exceptions
  - User Defined Exceptions
  - Throwing Exceptions
  - Catching Exceptions
- Orber Interceptors
  - Top of chapter
  - Using Interceptors
  - Interceptor Example
- OrberWeb
  - Top of chapter
  - Using OrberWeb
  - Starting OrberWeb
- Debugging
  - Top of chapter
  - Tools and FAQ

# 10 CORBA System and User Defined Exceptions

### 10.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 operations raises exception IDL-definition.

#### Status Field

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

Status | Description
'COMPLETED_YES' | The operation was invoked on the target object but an error occurred 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 occurred and it is impossible to decide if the request really reached the object or not.

Table 10.1: System Exceptions Status

#### 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.

#### Supported System Exceptions

The OMG CORBA specification defines the following exceptions:

- 'BAD_CONTEXT' - if a request does not contain 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 occurred in an ORB, which is unrecognized. You may consider contacting the ORB providers 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 object 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.

### 10.2 User Defined Exceptions

User exceptions is defined in IDL-files and is listed in operations 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();
      };
    };

### 10.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.

### 10.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.