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.

© 2010–2017 Ericsson AB
Licensed under the Apache License, Version 2.0.