When an expression for a dynamic property using a SQLTag is not = 192 (GOOD_DATA), the expression crashes with a runtime exception. A runtime exception error message popup window is unacceptable in a production environment, forcing me to do the following kind of expression in a bazillion places because of OPC Server issues:
Suppress all runtime exception error message popups, except fatal errors that would be clearly identified as such. Operators shouldn’t be exposed to these windows, developers only! Background logging would still record the gory details for analysis.
Have the exception handling instead be incorporated into the visual color overlay system already implemented for Tags and Indirect Tags (Bound to a component’s data quality attribute by the system developer person). This will give the operator visual feedback without freaking him/her out.
The first thing you mentioned, the runtime exception, sounds like a bug. Could you click “send to Inductive Automation” and/or help us reproduce it so that we can fix it?
IMO, operators should see/be exposed to errors. The idea being that hiding error messages often hides problems, which should be fixed. I know that stack traces=confidence decreasors, but these help you identify and fix issues with your project. In my mind, having a project break/lose functionality without indication is scarier than a break notification from the system (even with a stack trace) that causes no harm. That said, it’s important to strive for a correctly functioning system.
Background error logging does occur.
The component overlay system does indicate status to operators. For example, if they lose their network connection, they might see a green (stale data) overlay. How could you tie exception handling to component quality codes in a meaningful way?
I’ll be glad to send the error to you, but tech support is already aware of this condition since we worked out this workaround together a while back.
As far as hiding problems - I agree errors should never be hidden, but they should be presented based on the intended audience. A stack trace is totally inappropriate for an operator to see, that’s for the developer only. It should manifest itself in a way the operator can relate to, like color overlays for “broken” components with an alarm indication that would give the operator instructions, like call the developer or whatever action is appropriate.
A stack trace window in a production environment is caustic for the reputation of the developer as well as the software vendor. It implies that the software does not anticipate error conditions and handle them gracefully.
If you believe the condition I’m describing is a bug, then the bulk of this conversation may be much ado about nothing. I’ll send the error and we’ll find out!
Yes, please describe the error in more detail. It looks like that binding is doing nothing but protecting against the bad quality case. Are you saying that if you use a standard tag binding or indirect tag binding you get an error popping up when the quality goes poor? You should just get an overlay…
The error was forwarded to IA on the weekend. I can reliably create this error by using any “down” SQLTag in an expression. I guess everyone else has reliable OPC servers!
I can’t find the error you reported in our system. I’m guessing the error has something to do with a poor quality tag’s value becoming null and that null being used in some arithmetic - can you confirm?
I’m still a bit confused about the example you chose to post - why is that an expression at all?
As a followup to this issue, in Ignition 7.0.4 the binding system has been overhauled to use quality overlays to indicate any kind of binding problem (like the ones described above) instead of error popups. So whether your expression fails, a query fails, a tag as null, or anything, you’ll get a poor quality overlay for that component, and the cause of the problem will get put in the diagnostic log.
