error propagation across subsequent requests

[FabiolaDelaCueva · Accepted solution]

For more about the eternal battle of turning automatic error on or off, I refer you to Darren's presentation "An End to Brainless Programming"

---

@carlod80 wrote:

@Taggart: yes, Automatic Error Handling is turned on, but that's both my choice and DQMH's choice (the Request VI with AEH turned on was generated by DQMH, not me). Personally I would be very skeptic about globally turning off AEH in my environment, (feels like debugging will turn into a nightmare).

DQMH made a choice not to wire that destroy ref error to anything (and left AEH on): this leads the default behavior that I described: the "true" Error 56 being "preempted" (call it as you wish) by the Error 1. And it is effectively silenced, because in a chain of Requests you will only see a chain of Error 1 popups until the end of the chain (or until it is explicitly handled). This choice of not wiring that error in and out is what I'm asking about in my question (why, and how do DQMH people deal with the behavior I described).

---

DQMH assumes automatic error handling will be turned off. When creating a new DQMH from project template, the DQMH scripting code does turn auto error handling off. But when creating new event VIs, the DQMH scripting code is respecting the developer's environment setting. We have filed an internal issue (DQMH-588) for the DQMH code to turn automatic error handling off on created event VIs since DQMH was designed with automatic error handling turned off.  Thanks for bringing this to our attention.

Carlo, please turn off the automatic error handling from the Request and Wait for Reply event VIs. This should eliminate the red hearing you are seeing.

@drjdpowell wrote:

I recommend you guys always treat a timeout waiting for a reply as a failure (thus error).  All Modules should commit to replying in a reasonable period of time ("reasonable" being dependant on the application) and timeout values should be comfortably larger than that reasonable time.  Otherwise you turn any simple interaction into something requiring much more complex logic.

---

We have received direct requests to modify the way the DQMH Request and Reply works, we originally took our cue from the Wait on Notification VI, which does not return an error on timeout, but instead returns a Boolean... that is what the Request and Wait for Reply does when it calls the Wait on Notification. 

Ozfarmboy, I know you have requested this in the past, I couldn't find the feature request in the DQMH Feature Requests page. Do you have the link? If not, can you please add it and point to this discussion. Seems like you might get enough kudos to get this feature looked at the next DQMH release. 

Thanks,

Fab

[drjdpowell]

---

@FabiolaDelaCueva wrote:

...we originally took our cue from the Wait on Notification VI, which does not return an error on timeout, but instead returns a Boolean... that is what the Request and Wait for Reply does when it calls the Wait on Notification. 

---

A "reply" is quite different from a "notification".  We may, or may not, receive a notification in any particular interval of time, at the whim of the other process making the notification.  We may need to timeout and handle other business, before going back to waiting for a possible notification, but the failure to receive a notification in a particular period of time is (generally) not a failure on our part.

But a reply is the second part of a request-reply interaction initiated by us.  We expect, and require, a reply to our request, and failing to get one (which will be the case if we timeout and destroy the communication channel that the reply is to come on) means that we have failed in our attempted action.  This should be an error of some kind.

Don't use the Notifier API (something may happen) as the model of a Reply API (something should happen), even if you're building your Reply API using a Notifier.

[carlod80]

Thanks @Fab, that is (most of) the answer to my question. I still wonder why the error wire was not simply passed in and out of the Release Notifier VI, so that the upstream error, whatever the AEH setting, is passed downstream...

Sorry for the noise, I didn't mean to stir up a hornet's nest just because of my AEH setting... I always took it as a standard practice to leave it turned on to avoid errors from passing unnoticed, but given the feedback from everyone I will now reconsider this (thanks for the link to Darren's presentation).

Thanks again everyone!

[drjdpowell]

I suspect it would be best to make the scripted VIs work regardless of the Programmers desired AEH setting, as it is arguable whether AEH is good or bad.

[Darren]

Unlike many other LabVIEW IDE settings (auto grow on structures, show terminals as icons, etc.), Automatic Error Handling actually changes the functionality of executing code. As such, I feel that the decision as to whether or not to use AEH should be made at the framework level. Fab mentioned that DQMH was designed with AEH turned off. In my opinion, that means that all code in a DQMH module should also have AEH turned off. I think it will be a good change to have the DQMH scripting tools create event VIs with AEH turned off in a future DQMH release. For consistency, I wonder if the DQMH Validate Tool should also have a tester/fixer for ensuring that AEH is turned off on all the VIs in a DQMH module.

Also, it's my understanding that LabVIEW NXG will be moving in the direction that AEH is enabled/disabled as a project-wide setting, which I think is a good change. Although I am adamantly against AEH, I know that not everybody feels the same way, so having it be a feature that can be enabled/disabled at the project level (as opposed to the VI level in LabVIEW 20xx) seems like a very good change to me.

[FabiolaDelaCueva]

---

@drjdpowell wrote:

I suspect it would be best to make the scripted VIs work regardless of the Programmers desired AEH setting, as it is arguable whether AEH is good or bad.

---

As I mentioned above:

"

DQMH assumes automatic error handling will be turned off. When creating a new DQMH from project template, the DQMH scripting code does turn auto error handling off. But when creating new event VIs, the DQMH scripting code is respecting the developer's environment setting. We have filed an internal issue (DQMH-588) for the DQMH code to turn automatic error handling off on created event VIs since DQMH was designed with automatic error handling turned off.  Thanks for bringing this to our attention.

"

Filing an internal issue means we are working on fixing this issue and it will be included in the next release of DQMH. 

Thanks,

Fab

[FabiolaDelaCueva]

Hi Carlo,

The error is not passed through when the error reported would be a red herring, like in this case. Check out Darren's presentation. I will look up in more detail the code and give you a more complete answer later. I have to run now.

Thanks,

Fab