Rif.: Error not wired in Request and wait for reply in pubplic API VI

[MaxScz]

Sorry for the long title :D.

If I create a Request and wait for reply Event, in the Public API the Error Cluster from the release notifier VI doesn't get wired to the other error clusters. Please see picture and VI in the attachments.

If an error comes in the Request and wait for reply VI, the notifier does not get created, the release notifier tries to release an empty reference and throws an error. So LabVIEW starts to throw some pop-up windows, cause the error is not wired/handled. Is this a Bug in my DQMH software or is this a feature I did not see?
I am running the newest 4.2.1 Version of DQMH.

Max

[T.L.]

Hi Max,

if you disable automatic error handling dialogs in LabVIEW options, this dialog will disappear:

This my default settings since ages. If i need a dialog to show a user something happened, i do this explicitly on my own.

best regards

Thomas

[carlod80 · Accepted solution]

If I understand correctly the OP's question, there is a discussion of this problem here. Personally, I like to have automatic error handling turned on, but that's just me.

[FabiolaDelaCueva]

---

@carlod80 wrote:

If I understand correctly the OP's question, there is a discussion of this problem here. Personally, I like to have automatic error handling turned on, but that's just me.

---

The next release of DQMH will have the error out wired for that notifier and we will ensure that anything that is scripted has Automatic Error Handling off.

More on Automatic Error Handling:

Brainless LabVIEW is a good source, the slides are at http://bit.ly/brainlesslabview

At that link, Darren has included the youtube recording. The section of the video where Darren talks about automatic error handling starts at 10:38 and goes to 16:00. 

I was in the camp of having Automatic Error Handling ON, I have come to agree with Darren that automatic error handling is a crutch. Programmers don't pay close enough attention to the error propagation in their code, and they just assume automatic error handling will save them. We would prefer they spend the extra mental energy (and VI Analyzer runs) ensuring the error propagation is correct in the first place. Learning best practices for error propagation now will save them from trouble down the road.

Edit: One more thing, I really didn't like it when it was the end user who would get an automatic error handler error prompt. I better handle all the errors myself and ensure that when they do get a prompt for an error, it is in a format and language that is clear for them to understand and not a scary automatic LabVIEW error prompt.

Another good resource on this topic is Darren's "What to Expect When You're Expecting an Error" presentation, which also includes slides and a youtube recording: 

http://bit.ly/dnatterrors

Regards,

Fab

[MaxScz]

Thanks for your replies,

I didn´t know, that the AEH plays such an important role while working with LabVIEW. Thanks for the resources about the topic, now the unwired error makes sense to me.

For every one, who has to "repair" their code and turn the AEH off here is a quicksolution for this:
https://www.labviewforum.de/Thread-VI-Analyzer-Test-Disable-Automated-Error-Handling
Download the file, put it in the following folder ./<user>/Documents/LabVIEW Data/VI Analyzer Tests, restart LV, create a LV Analyzer Test, select the desired VIs and only check the user defined test, run test, done.

Edit: Here is another source from Darren
https://forums.ni.com/t5/VI-Analyzer-Enthusiasts/Test-Auto-Error-Handling-Detect-or-Correct/ta-p/350...