In general, you cannot safely prevent these exceptions from happening. Various 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 that an OPC operation can fail.

Instances of this class typically contain an inner exception that provides more specific details about the error that occurred. It is recommended to examine the inner exception, if available, to obtain more detailed information about the cause of the failure.

Various kinds of errors may be returned by OPC Data Client, e.g.:

• Errors returned by system calls when performing OPC-related operations.
• In OPC Classic, errors returned by COM/DCOM infrastructure, including RPC errors.
• In OPC UA, errors returned by communication infrastructure, including Web service errors.
• Error returned by OPC-UA Stack or SDK.
• Network-related errors.
• Errors reported by the OPC server you are connecting to.
• Errors detected by the OPC Data Client library.

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.

OPC Data Client “Classic” and OPC Data Client-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:

• COMException, especially common in OPC Classic.
• UAStatusCodeException, when the OPC-UA status code is not as expected.
• UAEngineException, for errors that originates in the OPC-UA engine and not in the OPC service (or OPC-UA SDK).
• UAServiceException, when an OPC-UA defined error occurs.
• LicenseException, if there is a problem with component’s license in OPC Data Client-UA.
• An exception from the lower level systems, such as .NET Framework, WCF, OPC-UA stack or SDK.

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

Because many errors are provided by the infrastructure that OPC Data Client 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. OPC Data Client.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 OPC Data Client “Classic” and OPC Data Client-UA operations, OpcException or UAException is the ONLY exception class that your code should be explicitly catching when calling OPC Data Client 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 OPC Data Client-COM, the actual error handling concepts (and related terminology) depend strongly on the programming language and development tool you are using, for example:

• In C++, if you are using the raw interfaces provided by the type library, each function call will return an HRESULT value that you will test using macros such as SUCCEEDED() or FAILED().
• In C++, if you are using “Compiler COM Support” (the #import directive), errors will be converted to exceptions of _com_error type.
• In VBScript, failed function calls will either generate run-time error (with On Error Goto 0), or fill in the Err object with information about the error (with On Error Resume Next).

In COM, OPC Data Client 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 OPC Data Client 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.

System.Object
   System.Exception
      System.ApplicationException
         OpcLabs.BaseLib.Exception2
            OpcLabs.BaseLib.OperationModel.OperationException
               OpcLabs.EasyOpc.UA.OperationModel.UAException
                  OpcLabs.EasyOpc.UA.OperationModel.UALogicalException

Target Platforms: .NET Framework: Windows 10 (selected versions), Windows 11 (selected versions), Windows Server 2016, Windows Server 2022; .NET: Linux, macOS, Microsoft Windows