OPC Studio User's Guide and Reference
OPC Classic Errors
OPC Classic is based on Microsoft COM/DCOM, and as such, the vast majority of exceptions you encounter is of type COMException (or derived from it). The HResult and ErrorId properties of the COMException contain a numeric identification of the problem, which you can use to distinguish between the specific error causes. These exceptions can be
A comprehensive list of possible error code cannot be given. Your program must always be ready to handle any error code that it does not explicitly know about. In most cases, you will be treating all errors the same way. In some cases, you may need to have a special handling for one or a few specific errors.
Internally, on the OPC level, errors in OPC XML-DA are reported and identified differently from COM/DCOM-based OPC Data Access. OPC Data Client, however, provides a uniform "view" of OPC DA and OPC XML-DA, allowing you to access OPC servers supporting these specifications in the same way. This, however, poses a challenge in usage scenarios where your code needs to make decisions based on specific kinds of errors reported by the OPC server. Ideally, for the same type of problem, you would like to receive the same error, regardless of whether the target is OPC-DA or OPC XML-DA.
OPC Studio attempts to resolve this problem by "harmonizing" the error information provided to you, even if it is originally generated differently. For errors arising directly fro OPC operations, OPC Data Client uses a ExtendedCOMException (or a derived class) as a base (innermost) exception. This exception class contains, besides an ErrorCode Property which contains the numerical code of the error (HRESULT) also a QualifiedName Property, which contains a unique identification of the error in form of a XML name with a namespace. For errors generated in OPC Classic specifications, OPC Data Client puts their HRESULT without change into the ErrorCode Property, and it derives the qualified name for well-known errors from the HRESULT. Conversely, for errors generated in OPC XML-DA, the qualified name is the primary error information, and OPC Data Client derives what the HRESULT would be, for well-known errors, from the qualified name, and stores it into the ErrorCode. This way, for common OPC errors, the information contained in these exception properties will be the same regardless of whether the error comes from COM/DCOM OPC, or from OPC XML.
You should use the Exception.GetBaseException Method to obtain the innermost (harmonized) exception.
Errors generated by Multiple Implementations of the client code are also harmonized, so that the base (innermost) exceptions are identical or similar. Note that the "wrapping" of these exceptions, i.e. the higher-level exceptions, may differ between the implementations. Errors related to setting up the OPC connection (such as determining the server's CLSID form its ProgID by OPCEnum) may also differ between implementations.
The harmonization only affects the exception type, and the ErrorCode Property and the QualifiedName Property. The error message itself may still differ in harmonized errors.
In addition, timeout errors that do not come from lower layers are harmonized to a TimeoutException or its derivation whenever feasible.
There are also vendor-specific errors, and error situations that are unique to either type of OPC technology or implementation. Obviously, in such cases, error harmonization is not possible.
Note: The error texts are for illustration only. They are subject to change without notice. Your program should never rely on the error texts; use the ErrorId, or specific identification properties of various exception types, to distinguish between specific errors.
In this case, you will typically receive a COMException "Invalid class string" (localized) with HResult of -2147221005 (0x800401F3), symbolically CO_E_CLASSSTRING. Of course, you will get the same exception if the intended OPC server is actually installed, but you have misspelled its ProgId.
In this case, you will typically receive a COMException "The RPC server is unavailable" (localized) with HResult of -2147023174 (0x800706BA). Of course, you will get the same exception if the intended computer is actually running and accessible, but you have misspelled its name or IP address.
In this case, you will typically receive a COMException "The item is no longer available in the server address space." (possibly localized) with HResult of -1073479673 (0xC0040007), symbolically OPC_E_UNKNOWNITEMID. Of course, you will get the same exception if the intended item actually exists, but you have misspelled its Item ID. This error is returned by the OPC server if the syntax of the Item ID conforms to the server's requirements, but the item does not exist. If even the syntax of the Item ID is incorrect, you will receive "The item ID does not conform to the server's syntax." (possibly localized) instead, with HResult of -1073479672 (0xC0040008), symbolically OPC_E_INVALIDITEMID.
In this case, you will typically receive one of the following COMException-s:
The above exceptions come from the client side, where OPC Data Client is pre-checking the access rights of the item before it actually attempts to perform the operation. If these checks succeed, but the operation is nevertheless rejected by the server, you will typically receive
The methods that do not have data quality in their results, and therefore must return an error instead of the value when the value is not present, include: