Check and Do vs. Try and Catch pattern in DQMH Event API Calls

[John_Neutron]

Hello DQMH Fans

My apologies if this has been covered before but I noticed a possible anti-pattern in the API VIs which generate the DQMH events: before attempting to generate the User Event a check is made to confirm if the Event RefNum is valid. This assumes that nothing changes between the two actions and I doubt that anything actually would but...

It seems to me (and I am happy for others to disagree/correct me) that it would be better to just try and generate the event and then catch any error resulting from the User-Event RefNum not being valid. This avoids the minuscule issue where the RefNum goes invalid between the check and the Generate User Event call and the user is surprised by an Error Code 1 instead of the custom DQMH error 403681. The error-catching implementation could be done a number of ways but to illustrate what I mean, here is an example:

Cheers

John

[FabiolaDelaCueva]

Hi John,

Thanks for bringing this up. I am looking at the code you proposed and it would still need some modifications. If there is an error coming into "error in", the code would "eat it up" and replace it with the Module Not Running error. 

I have these two options, I will have the rest of the Delacor team take a look and we can prioritize if we should invest time on making this change given the small possibility of it causing a problem.

Modification 1:

Modification 2:

Do you have any preference between the two options?

Thanks for your trust in DQMH.

Regards,

Fab

[John_Neutron]

Hi Fab

Thanks for the response and I completely understand that this wouldn't be a priority given all the other exciting features you have been developing.

I shall leave it entirely to you and your team to consider which error handling approach you prefer - I don't know if one will be easier than the others with regards to modifying and adding nodes with scripting. Of your suggestions, Modification-2  looks more like the NI style of wrapping everything in an error structure. It also prevents an unnecessary call to the Obtain Event Requests VI so think of the performance boost for the error case!

I hadn't spotted the issue with my suggestion - I thought that an error on the error-in terminal of the VI would flow to the error-out terminal via the error-precedence rules of the merge error node.

Cheers

John

[FabiolaDelaCueva]

Hi John,

We will keep it in mind and

---

@John_Neutron wrote:

I hadn't spotted the issue with my suggestion - I thought that an error on the error-in terminal of the VI would flow to the error-out terminal via the error-precedence rules of the merge error node.

Cheers

John

---

You are correct, the error would flow to the error-out terminal via the error-precedence rules of the merge error node. This is actually why we have in that VI the input error flowing to the top input in the merge error node. My eyes stopped at the error case, that will teach me not to answer posts late at night 😉

Regarding the wrapping everything into an error structure, if you have not seen Darren's stop to brainless presentation yet, I totally recommend taking a look at that: http://bit.ly/brainlesslabview

Regards,

Fab

dfd

[John_Neutron]

Hi Fab

Thanks for the clarification and especially for sharing Darren's Presentation. Finally, the yoke of oppressive 'best-practices' has been lifted and I am free to exercise logic and reason in all that I code.

Cheers

John

[Darren]

---

@John_Neutron wrote:

Finally, the yoke of oppressive 'best-practices' has been lifted and I am free to exercise logic and reason in all that I code.

Tell your friends. We'll eradicate those brainless LabVIEW practices, one programmer at a time.