Error handling rationale

[bratdv]

Hi,

By default, the error message enqueued in Check Loop Error.vi is not flagged as a Priority Message:

I wonder why is this? In the case when multiple messages are already in the queue, error case executes only at the very end. Don't we want to handle an error ASAP?

I know I can create a child class and override the VI, but honestly I am afraid to do so, since I do not have a lot of experience with OOP and am not sure how to manage/maintain this new class accross multiple projects:where to store in on disk, how build an executables with it, etc.

Thank you!

Best,

Anton.

[Ozfarmboy]

This question comes up every so often.  I asked it back in the day too.

The general feeling is that messing with the queue order is generally a bad thing, and should be done so exceedingly sparingly. It is recommended that errors are handled as close to the error source as possible. Only the Stop module is high priority because normally you need that to happen right away.

In the early days, my modules were doing a lot of self-enqueuing, and therefore the MHL is being buffered up quite a bit - and hence if an error occurred then it would be at the end of that queue waiting to be handled. What I ended up doing to get around this is I check if there was an error coming out of the MHL case structure, and flushing the queue if there was. I do this before the DQMH Error Handling VI, so that the very next item in the queue will be the error case. But I've essentially aborted all enqueued cases as a result of this. In the end I was ok with this process because I didn't want the subsequent cases to be acted on if an error occurred half way through. The error case was designed more of a catch all. But we don't write code like this anymore, and avoid the self-enqueueing. This was an early piece of code.

At the end of the day, you can override the DQMH Queue class to make it do what you want.