3.7.2.4.7 Exceptions
If the CORBA object method that is invoked by the client raises
an exception, that exception is caught by the TP Framework and is
eventually returned to the client. This is true even if
deactivate_object()
is invoked and raises an
exception.
The client will never be notified about exceptions that are
raised in deactivate_object()
. It is the
responsibility of the application code to check that the stored
state of the CORBA object is consistent. For example, the
application code could save a persistent flag that indicates
whether or not deactivate_object()
successfully saved
the state. That flag can then be checked in
activate_object()
.
If an error occurs while executing
deactivate_object()
, the application code should raise
either a CORBA standard exception or a
DeactivateObjectFailed
exception If
deactivate_object()
was invoked by the TP Framework,
the TP Framework catches the exception and the following events
occur:
- The object is deactivated.
- If the client initiated a transaction, the transaction is not rolled back.
- The client is not notified of the exception that is raised in
deactivate_object()
. - Based on which exception is raised, a message is logged to the
user log (
ULOG
) file, as follows:-
TobjS::DeactivateObjectFailed
-
"TPFW_CAT:27: ERROR: De-activating object - application raised TobjS::DeactivateObjectFailed. Reason =
reason
. Interface =
interfaceName
, OID =
oid
"
-
CORBA::Exception
-
"TPFW_CAT:28: ERROR: De-activating object - CORBA Exception not handled by application. Exception ID = exceptionID. Interface = interfaceName, OID = oid"
-
Other exception
-
"TPFW_CAT:29: ERROR: De-activating object - Unknown Exception not handled by application. Exception ID = exceptionID. Interface = interfaceName, OID = oid"
-
Parent topic: Tobj_ServantBase::deactivate_object()