VisiBroker for Java Developer’s Guide : CORBA exceptions

CORBA exceptions
This section provides information about CORBA exceptions that can be thrown by the VisiBroker ORB, and explains possible causes for VisiBroker throwing them.
CORBA exception descriptions
The following table lists CORBA exceptions, and explains reasons why the VisiBroker ORB might throw them.
An attempt to call the CORBA::Request::get_response() or CORBA::Request::poll_response() methods may have occurred prior to actually sending the request. An attempt to call the exception::get_client_info() method may have occurred outside of the implementation of a remote method invocation. This function is only valid within the implementation of a remote invocation. An operation was called on the VisiBroker ORB that was already shut down.
A server throws this exception if a request is received for an operation that is not defined on that implementation's interface. Ensure that the client and server were compiled from the same IDL. The CORBA::Request::return_value() method throws this exception if the request was not set to have a return value. If a return value is expected when making a DII call, be sure to set the return value type by calling the CORBA::Request::set_return_type() method.
Sequences throw CORBA::BAD_PARAM if an access is attempted to an invalid index. Make sure you use the length() method to set the length of the sequence before storing or retrieving elements of the sequence.
The VisiBroker ORB throws this exception if null reference is passed. An attempt may have been made to insert a null object reference into an Any.
An attempt may have been made to construct a TypeCode with an invalid kind value.
Using the DII and one way method invocations, an OUT argument may have been specified. An interface repository throws this exception if an argument passed into an IR object's operation conflicts with its existing settings. See the compiler errors for more information.
An attempt to marshal Unicode characters with Output.write_char() or Output.write_stringfails.
The ORB_init() method may not have been called. All clients must call the ORB_init() method prior to performing any VisiBroker ORB-related operations. This call is typically made immediately upon program startup at the top of the main routine.
If an object implementation cannot locate an interface repository during an invocation of the get_interface() method, this exception will be thrown to the client. Ensure that an Interface Repository is running, and that the requested object's interface definition has been loaded into the Interface Repository.
The VisiBroker ORB will throw this exception if an object reference is obtained that contains no usable profiles. The ORB::string_to_object() method will throw this exception if the stringified object reference does not begin with the characters "IOR:".
CORBA::INVALID_
TRANSACTION
Thrown anytime the client gets an IOR which will conflict with the QOS policies that have been set. If the Rebind Policy has a value of NO_REBIND,NO_CONNECT, or VB_NOTIFY_REBIND and an invocation on a bound object reference results in an object forward or a location forward message.
Raised by the VisiBroker ORB, when it detects a mismatch between the TransactionPolicy in the IOR and the current transaction mode.
Heuristic OMG-specified exceptions
A heuristic decision is a unilateral decision made by a participant in a transaction to commit or rollback updates without first obtaining the consensus outcome determined by the VisiTransact Transaction Service. See the VisiBroker VisiTransact Guide for more information about heuristics.
The following table lists heuristic exceptions as defined by the OMG CORBAservices specification, and explains reasons why they might be thrown.
The VisiTransact Transaction Service invoked rollback() on a Resource object that already made a heuristic decision to commit its work. The Resource raises the HeuristicCommit exception to indicate its state to the VisiTransact Transaction Service.
The VisiTransact Transaction Service invokes commit() or rollback() on a Resource object that may or may not have made a heuristic decision.
The VisiTransact Transaction Service invokes commit() or rollback() on a Resource object that has made a heuristic decision, but not made all the relevant updates.
The VisiTransact Transaction Service invokes commit() on a Resource object that has made a heuristic decision to rollback its work. The Resource raises the HeuristicRollback exception to indicate its state to the VisiTransact Transaction Service.
Other OMG-specified exceptions
The following table lists other exceptions as defined by the OMG CORBAservices specification, and explains reasons why the VisiTransact Transaction Service might throw them. For more information see “CORBA exceptions”.
This exception could be raised if register_synchronization() is invoked after the transaction has already been prepared.
This exception is raised when resume() is invoked and the parameter is not a null object reference, and is also not valid in the current execution environment.
An invocation of replay_completion() or commit() on a Resource that has not yet prepared will result in this exception.
The commit(), rollback(), or rollback_only() methods may raise this exception if there is no transaction associated with the client thread at invocation.
A subsequent begin() invocation was performed after a transaction was already begun. If your transactional object needs to operate within a transaction, it must first check to see if a transaction has already begun before invoking begin().
The create_subtransaction() method was invoked, but VisiTransact Transaction Manager does not support subtransactions.
The Control object cannot provide the Terminator or Coordinator objects when Control::get_terminator() or Control::get_coordinator() are invoked.
The VisiTransact Transaction Service restricts the availability of the PropagationContext, and will not return it upon an invocation of Coordinator::get_txcontext().
The get_response() and get_next_response() methods may raise this exception if the transaction associated with the request is not the same as the transaction associated with the invoking thread.