Hello,
I had a further look into the Exceptions vs Bad Quality, and found it more complicated than it seems at first. In the OPC "Classic" world, the distinction between the two came naturally from the standard, because the errors are reported as HRESULT-s on method calls, and if there is an error, there is no quality to talk about. And the quality, when available, generally indicated problems between the OPC server and the target device.
In OPC-UA, protocol-level (Client-to-Server) errors (except those coming from higher-level protocols used to encapsulate the UA communication) are all merged into the UA StatusCode, together with qualities. The idea of distinguishing between Client-to-Server and Server-to-Device errors does not appear directly in OPC-UA, although we feel that it is very useful and want to keep that distinction in our API. The current implementation makes an assumption that Severity=Bad in UA Status Code means Client-to-Server error (and therefore create an Exception), wherease other Severities mean "success" on Client-to-Server level, and are interpreted as a result from Server-to-Device communication (and therefore provide valid UAAttributeData). It looks like that this not a fully satisfactory approach.
The OPC UA Specification provides little guidance on how to make the distinction we want. The only way I can think of now is to identify specific UA StatusCode-s that have to do with Server-to-Device communications, and treat the rest as Client-to-Server statuses (the majority of them seem to be Client-to-Server). We can then change the implementation so that these Server-to-Device codes do not create an Exception. I have currently identified about 3 such StatusCode-s that are related to Server-to-Device comms, but this needs to be further verified for compatibility with existing servers etc.
Can you tell me the full status code (all bits) that you are getting from your server and that you want to be treated differently?
Thank you
