Tango Core Classes Reference
9.2.5
|
All the exception thrown by this API are Tango::DevFailed exception. This exception is a variable length array of Tango::DevError type. The Tango::DevError type is a four fields structure. These fields are :
This is a variable length array in order to transmit to the client what is the primary error reason. The sequence element 0 describes the primary error. An exception class hierarchy has been implemented within the API to ease API programmers task. All the exception classes inherits from the Tango::DevFailed class. Except for the NamedDevFaildeList exception class, they don’t add any new fields to the exception, they just allow easy "catching". Exception classes thrown only by the API layer are :
On top of these classes, exception thrown by the device (Tango::DevFailed exception) are directly passed to the client.
This exception is thrown when a problem occurs during the connection establishment between the application and the device. The API is stateless. This means that DeviceProxy constructors filter most of the exception except for cases described in the following table.
Method name | device type | error type | Level | reason |
---|---|---|---|---|
DeviceProxy constructor | with database | TANGO_HOST not set | 0 | API_TangoHostNotSet |
Device not defined in db or Alias not defined in db | 0 | DB_DeviceNotDefined | ||
1 | API_CommandFailed | |||
2 | API_DeviceNotDefined | |||
with database specified in dev name | database server not running | 0 | API_CorbaException | |
1 | API_CantConnectToDatabase | |||
without database | Server running but device not defined in server | 0 | API_CorbaException | |
1 | API_DeviceNotExported | |||
AttributeProxy constructor | with database | TANGO_HOST not set | 0 | API_TangoHostNotSet |
Device not defined in db | 0 | DB_DeviceNotDefined | ||
1 | API_CommandFailed | |||
2 | API_DeviceNotDefined | |||
Alias not defined in db | 0 | DB_SQLError | ||
1 | API_CommandFailed | |||
2 | API_AliasNotDefined | |||
with database specified in dev name | database server not running | 0 | API_CorbaException | |
1 | API_CantConnectToDatabase | |||
DeviceProxy or AttributeProxy method call (except command_inout, read_attribute) | without database | Server not running | 0 | API_CorbaException |
1 | API_ServerNotRunning | |||
with database | Server ot running | 0 | API_DeviceNotExported | |
Dead server | 0 | API_CorbaException | ||
1 | API_CantConnectToDevice | |||
Dead database server when reconnection needed | 0 | API_CorbaException | ||
1 | API_CantConnectToDatabase | |||
DeviceProxy command_inout and read_attribute or AttributeProxy read and write | without database | Server not running | 0 | API_DeviceNotExported |
1 | API_ServerNotRunning | |||
2 | API_CommandFailed | |||
with database | Server not running | 0 | API_DeviceNotExported | |
1 | API_CommandFailed | |||
Dead server | 0 | API_CorbaException | ||
1 | API_CantConnectToDevice | |||
2 | API_CommandFailed or API_AttributeFailed | |||
Dead database server when re-connection needed | 0 | API_DeviceNotExported | ||
1 | API_CantConnectToDatabase | |||
2 | API_CommandFailed |
The desc DevError structure field allows a user to get more precise information. These informations are (according to the reason field) :
This exception is thrown when a communication problem is detected during the communication between the client application and the device server. It is a two levels Tango::DevError structure. In case of time-out, the DevError structures fields are:
Level | Reason | Desc | Severity |
---|---|---|---|
0 | API_CorbaException | CORBA exception fields translated into a string | ERR |
1 | API_DeviceTimedOut | String with time-out value and device name | ERR |
For all other communication errors, the DevError structures fields are:
Level | Reason | Desc | Severity |
---|---|---|---|
0 | API_CorbaException | CORBA exception fields translated into a string | ERR |
1 | API_CommunicationFailed | String with device, method, command/attribute name | ERR |
This exception has only one level of Tango::DevError structure. The possible value for the reason field are :
This exception has only one level of Tango::DevError structure. The reason field is set to API_NonDatabaseDevice. This exception is thrown by the API when using the DeviceProxy or AttributeProxy class database access for non-database device.
This exception has only one level of Tango::DevError structure. The possible value for the reason field are :
This exception is thrown by the API layer when a request to a feature implemented in Tango device interface release n is requested for a device implementing Tango device interface n-x. There is one possible value for the reason field which is API_UnsupportedFeature.
This exception is thrown by the API layer when a the asynchronous model id badly used. This exception has only one level of Tango::DevError structure. The possible value for the reason field are :
This exception is thrown by the API layer when:
There is one possible value for the reason field which is API_AsynReplyNotArrived.
This exception is thrown by the API layer when subscribing or unsubscribing from an event failed. This exception has only one level of Tango::DevError structure. The possible value for the reason field are :
This exception is only thrown by the DeviceProxy::write_attributes() method. In this case, it is necessary to have a new class of exception to transfer the error stack for several attribute(s) which failed during the writing. Therefore, this exception class contains for each attributes which failed :
The following piece of code is an example of how to use this class exception
This exception inherits from Tango::DevFailed. It is possible to catch it with a "catch DevFailed" catch block. In this case, like any other DevFailed exception, there is only one error stack. This stack is initialised with the name of all the attributes which failed in its "reason" field.
This exception is thrown by the API layer when a device locked by the process has been unlocked by an admin client. This exception has two levels of Tango::DevError structure. There is only possible value for the reason field which is
The first level is the message reported by the Tango kernel from the server side. The second layer is added by the client API layer with informations on which API call generates the exception and device name.