DVR Error Handling

[Rolf Kalbermatter]

6 hours ago, Ernesto Aneiros said:

I also plan to connect both not because I like wasting my own programming time (as negligible as connecting an extra terminal might be) but because LV's behavior here is _inconsistent_ between versions and _silently_ changed. What guarantees do we have that it will not change again?

I prefer to only wire 1 of them and NOT enable automatic error handling in the VI. My default for automatic error handling is "disable". I find it a terrible idea to have random error popups show up if you want to ignore some errors and don't want to place thousends of Clear Error.vi all around the place.

[ShaunR]

As per usual, I'm n outlier here. I hardly ever disable Automatic Error Handling and prefer to use Clear Error.vi where necessary (although I have my own Clear Error.vi which is re-entrant rather than the native on which is not).

My reasoning is thus.

1. It demonstrates that the error condition has been considered and a specific decision has been made to ignore it.
2. Automated test harnesses reveal uncaught errors (by never completeing) wheras they may pass if AEH is turned off.
3. I'd rather an error dialogue pop up on a customer machine which at least gives me some iinformation of where to look if an unconsidered error occured rather than them saying "I press this button and it doesn't work".

6 hours ago, Michael Aivaliotis said:

Automatic error handling is for noobs.

Turning it off is is a code-smell for "cowboy coder"

 

Edited November 1, 2018 by ShaunR

[Rolf Kalbermatter]

23 minutes ago, ShaunR said:

As per usual, I'm n outlier here. I hardly ever disable Automatic Error Handling and prefer to use Clear Error.vi where necessary (although I have my own Clear Error.vi which is re-entrant rather than the native on which is not).

My reasoning is thus.

1. It demonstrates that the error condition has been considered and a specific decision has been made to ignore it.
2. Automated test harnesses reveal uncaught errors (by never completeing) wheras they may pass if AEH is turned off.
3. I'd rather an error dialogue pop up on a customer machine which at least gives me some iinformation of where to look if an unconsidered error occured rather than them saying "I press this button and it doesn't work".

Turning it off is is a code-smell for "cowboy coder"

 

In my LabVIEW 2016 in which I'm still mostly working Clear Error.vi is set as clone and to be inlined!

[smithd]

2 hours ago, rolfk said:

In my LabVIEW 2016 in which I'm still mostly working Clear Error.vi is set as clone and to be inlined!

Yes they fixed some of those silly things in more recent versions. Also turning off the call chain on error cluster to code so that RT systems didn't do tons of string manipulation. If I remember his posts correctly shaun uses some ancient version like labview 8.1 or something 

Edited November 2, 2018 by smithd

[Aristos Queue]

12 hours ago, Ernesto Aneiros said:

As we have already seen, a statement from R&D is not a strong guarantee.

I also plan to connect both not because I like wasting my own programming time (as negligible as connecting an extra terminal might be) but because LV's behavior here is _inconsistent_ between versions and _silently_ changed. What guarantees do we have that it will not change again?

Never mind. You're right. Sorry. 

[Aristos Queue]

I decided my previous reply could be taken too snarkily... not what I intended. 

Let me be explain -- Ernesto is right, and with the lens he's looking through, it's a reasonable position. There's a rather substantial difference between a casual refactor that changed a terminal to be consistent with all other terminals and a foundational logic shift required to make two terminals that are literally the same address in memory return different values -- but that's something I can know with deep knowledge of the code underlying these two issues. No way for Ernesto or any other customer to recognize that. One can be done just by removing what appeared to be a bug; the other would require significant and deliberate retooling of the code. Not to mention it would break regression tests (tests that don't exist for automatic error handling since at the time that feature came along, there wasn't a good way to automatically test for anything that triggered dialogs requiring human acknowledgement). 

There are levels of trust between tool vendor and tool user, and once those are breeched, the promises of the vendor aren't worth anything. That's the case here. So even explaining all of the foregoing logic doesn't really suffice to say that Ernesto is wrong in his defensive coding practices. That's something NI has to earn back for that user. So perhaps if the bug with the auto error handling gets fixed and nothing changes about the errors of the accessors for another couple versions, we can get to the point where Ernesto feels comfortable removing the unnecessary bits. But until then, he's right to continue his current practice, and I shouldn't have said otherwise. I apologize. 

[MikaelH]

This is how I clear errors.

[Michael Aivaliotis]

If that's real, please add it to OpenGDS, like now!

[MikaelH]

Sure I'll add it, I thought everyone had a VI like that. 

We use it to indicate that the developer is aware that an error could be generated at this point in the code. It helps when we do code review. 

[Rolf Kalbermatter]

On 11/2/2018 at 6:46 AM, MikaelH said:

This is how I clear errors.

?

Edited November 8, 2018 by rolfk

[Ernesto Aneiros]

Thank you Aristos for your response, I can tell you gave it a bit of thought before responding.

10 hours ago, Aristos Queue said:

There are levels of trust between tool vendor and tool user, and once those are breeched, the promises of the vendor aren't worth anything.

You really hit the nail on the head here and get to the core of my issue. When my compiler silently changes behavior behind my back my existential anxiety levels tend to go through the roof  "If X changed... what _else_ did?" In this case it was something rather benign, but... trust is hard to gain but easy to lose. I am really happy that someone with your experience in LV R&D shares the same point of view.

Also, if my original post came across as harshly worded then, I too, should apologize. Thanks for your response!

[Michael Aivaliotis]

On 11/1/2018 at 4:45 PM, ShaunR said:

Turning it (automatic error handling) off is is a code-smell for "cowboy coder" 

If you don't already have a systematic way to manage errors in your code and are relying on automatic error handling exclusively, then that's a problem. Automatic error handling has some limited usefulness early on in development perhaps, to detect areas of your code that are not plugged into your current error handling system. However you shouldn't depend on it exclusively for handling errors. 

[ShaunR]

1 hour ago, Michael Aivaliotis said:

However you shouldn't depend on it exclusively for handling errors. 

Agreed. But it's the unhandled ones you have to worry about. and the ones that annoy customers the most

Edited November 14, 2018 by ShaunR

[Aristos Queue]

I agree with Shaun. By the time you ship, of course, you shouldn't care whether auto error handling is on or off (your VI Analyzer tests caught those), but it is invaluable during early development. And if you did miss something (developer submitted a VI late on deadline and didn't quite follow procedure or test machine had a bad day and skipped a step of your build or whatever), having AEH enabled can save you a wealth of time.

[Michael Aivaliotis]

So basically, if someone forgot to wire the error out. Gotcha.