Page History

\\
\] documentsTODO: check out this document and learn how previoussError field shall be filled.. Here, we will discuss the basic concepts. When there was no error, struct Completion contains the timestamp, the non-error type (ACSErrTypeOK) and code (ACSErrOK) and an empty previousError (error trace). BACI does not define values of the completion code, because it is open to particular implementations.
When there is an error, completion returns information that allows to pinpoint the reasons; previousError data structure contains detailed information about the error, either used to display or log the information - see the documents on error handling \[3\] and logging \[4\] for more.
\\
Listing 1: Definition of  ACSErrType  extracetd by acserr.idl.
#ifndef _ACSERR_IDL_
#define _ACSERR_IDL_
\\
#pragma prefix "alma"
\\
module ACSErr \{
\\
...
\\
    typedef unsigned long ACSErrType;
    typedef unsigned long ErrorCode;
\\
...
\\
\};
\\
#endif
\\
Error types and their corresponding codes are defined in XML files. For each error type, a unique XML file must be defined by the developer. The type ACSErrTypeMonitor is reserved for monitor callbacks that can be either time or value triggered.
\\
Listing 2: The XML for ACSErrTypeMonitor (ACSErrTypeMonitor.xml).
<?xml version="1.0" encoding="UTF-8"?>
 <Type xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="ACSError.xsd" name="ACSErrTypeMonitor" 
type="1" _prefix="alma">
 <Code name="ACSErrMonitorOnTimer" shortDescription="A regular timer monitor triggered the event." description="A regular timer monitor triggered the event."/>
 <Code name="ACSErrMonitorOnValue" shortDescription="The value changed by a specified amount or more." description="The value changed by a specified amount or more."/>
</Type>
\\
Code is automatically generated from the XML file.
Listing 3: Definition of ACS ACSErrTypeMonitor type.
#ifndef  _ACSErrTypeMonitor_IDL_
#define  _ACSErrTypeMonitor_IDL_
\\
#include <acserr.idl>
\\
#pragma prefix "alma"
\\
module ACSErr \{
 // type
 const ACSErr::ACSErrType ACSErrTypeMonitor = 1;
\};
\\
module ACSErrTypeMonitor \{QUESTION: What error type and what error code should be used when BACI property wants to say that it couldn't obtain a valid value from the hardware.
\\
When a new monitor is created, BACI property is obliged to call working() callback method within normal_timeout. It is possible that the hardware cannot respond by the specified time, but BACI property still has to call working() callback method so that the client won't time out. When calling working(), BACI property has to pass some value as the first argument, but that value will be a dummy value (because it is not the value that hardware returns). Thus, BACI property has to tell the client that the value is dummy somehow. Is there a standard way for that? Or, does the device server developer have to define such error code/type for each device?
\\
 //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
\\
The type ACSErrTypeAlarm is reserved for alarm messages that originate from the property value.
 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. 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.