Before I get to the specifics of the question, here is a more general statement:
The QuickOPC design concept is based on the idea that the aim of the component is to deliver the data,or perform the requested operation if possible. In casy of a problem the component:
1. Tries to remedy the situation, if possible (there may be workarounds for things like missing server features etc.). In this case you won't even know that this has happened, through the "normal" API channels (it might be in the logs, but that's for troubleshooting, not for normal operations).
2. If the above is not possible, you get to know about the problem through the API; if it affects an operation that spans a time range (like subscription), the component will keep trying to fulfill what it has been asked to do.
In the second case, to us, all errors are about the same - it does not matter what it was; it is up to the user to decide whether the problem needs addressing or how. The range of possible problems is enormous - client, server, network, configuration of them, etc. We do not generally expect the *software* to handle the errors, or handle some errors differently . It is possible to do, but it is not something we are designing for. Also the details of the errors are change to subject.
Now to your question: Are we talking about the situation when the client (your app) certificate is not trusted by the server (that is the "controller")?
If so, what is there on the client that you want to do differently from other error situations, and why? Is it just to provide better diagnostics to the operators of the software, or is there something more involved? The way we see it, as explained above, this error just like thousand other possible errors that can happen - somebody needs act upon it and resolve it, based on what the error message says - or not?
Thank you