QuickOPC User's Guide and Reference
Error Model in imperative programming
Development Models > Imperative Programming Model > Error Model in imperative programming

Various kinds of errors may be returned by QuickOPC, e.g.:

In general, you cannot reliably prevent all these errors from happening. Many conditions external to your code can cause OPC failures, e.g. network problems, improper OPC server configuration, etc. For this reason, you should always expect than OPC operation can fail.

QuickOPC “Classic” and QuickOPC-UA each define one new type of exception, called OpcException (for OPC “Classic”), or UAException (for OPC-UA), derived from the Exception object. This exception is for all errors arising from OPC operations.

More details about the cause of the problem can be found by interrogating the InnerException property of OpcException or UAException, or by examining the ErrorId property. In most scenarios, however, your code will be handling all OpcException-s or UAException-s in the same way, independent of the inner exception or error code.

The InnerException can be:

For more details, see OPC Classic Errors or OPC UA Errors, respectively.

Because many errors are provided by the infrastructure that QuickOPC is using, there is no way to provide a comprehensive list of all possible errors. You can, however, be sure that all error will be reported in the way described here, and therefore they can be handled as needed.

If you need to display a meaningful error message to the user, or log it for further diagnostics, it is best to take the OpcException or UAException instance, obtain its base exception using GetBaseException method, and retrieve its Message property. The error message obtained in this way is closest to the actual cause of the problem. QuickOPC.NET even tries to fill in the error text in cases when the system or OPC server has not provided it.

It should be noted that for QuickOPC “Classic” and QuickOPC-UA operations, OpcException or UAException is the ONLY exception class that your code should be explicitly catching when calling QuickOPC methods or getting properties. This is because you cannot safely influence or predict whether the exception will or will not be thrown. Other kinds of exception, such as those related to argument checking, should NOT be caught by typical application code, because they either indicate a programming bug in your code, or an irrecoverable system problem.

In QuickOPC-COM, the actual error handling concepts (and related terminology) depend strongly on the programming language and development tool you are using, for example:

In COM, QuickOPC single-operation methods return their success/failure indication using the standard HRESULT and possibly IErrorInfo approaches. This allows you to obtain the error code, and sometimes additional pieces of information such as Description, and Source. The actual type of exception thrown (as discussed above) is hidden using this mechanism. If you need the exception object, use an alternative QuickOPC method that performs multiple operations at once. Such methods return the success/failure information through the Exception property in the OperationResult (or derived) objects they return, allowing you to obtain the full extent of information associated with the error.

See Also