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