...
Alarms as defined above are notifications about the state of the controlled property. Alarms are asynchronous and completely independent events. They have nothing to do with errors that occur during execution flow. In case such errors occur, the type and code values indicate this error condition, and the variable called error may contain a pointer to another completion structure.
...
The
...
particular
...
values
...
of
...
the
...
type
...
and
...
code
...
are
...
specific
...
to
...
the
...
server
...
implementation.
| Wiki Markup |
|---|
The completion structure may have a pointer to yet another completion, and so on. We see that all those completion structures form a linked list in the recursive error sequence, which called error stack.QUESTION: Again, Completion structure does not have a pointer to another completion. There is actually a linked list of ACSErr:ErrorTrace in previousError variable, but ACSErr::ErrorTrace does not contain a pointer to Completion structure according to the reference document 2. Does this sentence mean the device server can extend Completion structure as they want? If so, is it necessary to address this issue here? Hence it is possible to return and analyze the full stack of errors in the method call sequence, as specified in \[3\]. This is usually done by the ACS libraries, either in the BACI server or in the Abeans \[5\] client libraries. The application programmer is relieved from this work. We will therefore not go into details here. If the Completion type and code indicate an error-free condition, the error stack must be empty.
Errors and alarms are returned through the completion structure and not via CORBA exceptions, because most of the method calls are asynchronous. Callbacks, which are executed on the client in a separate thread, cannot raise exceptions. For reasons of uniformity, also synchronously executed methods that deal with control processes, return the same completion structure.
If methods on remote objects (either Component or property) fail for unexpected reasons, in particular methods that do not even return a completion, such as calls to characteristics or invocation of monitors, then, and only then, exceptions are thrown. If the remote object can not be reached, then the local ORB raises a CORBA::NO_IMPLEMENT exception. If the remote object can not finish the request for whatever reason, it raises CORBA::NO_RESOURCES. These exceptions are unchecked, i.e. they are not predeclared in the signature of the method in the IDL file. |
...