...
| Code Block | ||||
|---|---|---|---|---|
| ||||
#ifndef _ACSErrTypeMonitor_IDL_
#define _ACSErrTypeMonitor_IDL_
#include <acserr.idl>
#pragma prefix "alma"
module ACSErr {
type
const ACSErr::ACSErrType ACSErrTypeMonitor = 1;
};
module ACSErrTypeMonitor {
//ED: A regular timer monitor triggered the event.
const ACSErr::ErrorCode ACSErrMonitorOnTimer = 0;
//ED: The value changed by a specified amount or more.
const ACSErr::ErrorCode ACSErrMonitorOnValue = 1;
// exceptions:
};//module
#endif | ||||
| Wiki Markup |
The
...
type
...
ACSErrTypeAlarm
...
is
...
reserved
...
for
...
alarm
...
messages
...
that
...
originate
...
from
...
the
...
property
...
value.
| Code Block | ||
|---|---|---|
| ||
Listing 4: Definition of ACS ACSErrTypeAlarm type. #ifndef _ACSErrTypeAlarm_IDL_ #define _ACSErrTypeAlarm_IDL_ \\ #include <acserr.idl> \\ #pragma prefix "alma" \\ module ACSErr \{ // type const ACSErr::ACSErrType ACSErrTypeAlarm = 2; \}; \\ module ACSErrTypeAlarm \{ \\ //ED: All alarm conditions have disappeared. const ACSErr::ErrorCode ACSErrAlarmCleared = 0; //ED: At least one alarm condition remains. const ACSErr::ErrorCode ACSErrAlarmChanged = 1; //ED: Value below alarm LoLo (includes hysteresis). const ACSErr::ErrorCode ACSErrAlarmLow = 2; //ED: Value above alarm HiHi (includes hysteresis). const ACSErr::ErrorCode ACSErrAlarmHigh = 3; //ED: An alarm on the status determined by software. const ACSErr::ErrorCode ACSErrAlarmSoftware = 4; //ED: An alarm on the status from the hardware. const ACSErr::ErrorCode ACSErrAlarmHardware = 5; \\ // exceptions: \\ \}; \\ |
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.
| Wiki Markup |
|---|
structure. QUESTION: What is "variable called error"? Such variable does not exist in Completion structure. It does not even contain a variable that holds a pointer to another completion structure. previousError fields in Completion structure only contains the array of ACSErr::ErrorTrace.
\\
Maybe this sentence could be simply removed?The particular values of the type and code are specific to the server implementation.
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. |
...