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

## 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(); }; };`

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

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