Do you wire the error out of sending requests?

[Shiv0921]

Looking for a logic check. Any time I've been sending requests I've been wiring the error out of the send request vis. But when a module of my program has errored out & stopped I want to be able to keep using the rest of the program without having errors thrown any time that the now dead module is included in a batch of messages being sent out.  This makes me feel like I shouldn't have the errors wired out of sending requests? Because all it will tell me is if my module is alive, and I don't need to be reminded that its not when the program will already be aware that its not following the broadcast of whatever caused the module to stop. 

I'm still learning what habits to have with DQMH and this is making me wonder if I'll stop wiring the error out of when I send requests, (providing that I always incorporate other code to catch the module stopping in the first place). But could there be something else important that I miss if I do that? Wanted to ask for thoughts before I start doing this. 

[drjdpowell]

When a module A sends a message to module B, this can represent one of two things:

• A is using B as part of doing its job, in which case B no longer existing is an error that stops A completing its job.
• A is providing information that B requires for its job, in which case B no longer existing is no concern of A.

It isn't super clear which of these two represents your case.  I would guess the second, in which case you are probably right to ignore the error 

[joerg.hampel · Accepted solution]

I'll ramp up the dogma of my answers in small steps:

1. In my experience, any tomfoolery with error clusters leads to head ache eventually. Today, you expect one of your modules to "error out and stop" and are ok with it. In three months' time, another module actually breaks and stops in a situation where you don't expect it - now, you have no information and no clues to start your debugging. 
   
   
2. In my opinion, any unhandled or unwired error cluster is a code smell and a work-around for a design that is suboptimal and needs fixing.
   
   
3. In our team, we all agree that it is forbidden to leave any error outputs unwired. We depend on every single bit of information when looking for weird behaviour. 

Long story short: My recommendation for you is to change the way your module reacts to errors. Alternatively, change how your batch of messages is created or sent out depending on the module status.

If you don't agree with my view, then I'd recommend to at least document very clearly why you're leaving the error outs unwired.

Btw, I don't think this is specific to DQMH or even to LabVIEW, it is how I see software development principles. 

[altenbach]

---

@joerg.hampel wrote:

1. In our team, we all agree that it is forbidden to leave any error outputs unwired. We depend on every single bit of information when looking for weird behaviour. 

---

The main problem with unwired error outs is that automatic error handling is enabled by default and will take over, generating a popup and potentially stalling dataflow. (but you can turn automatic error handling off!).

The best way to 100% ignore an error is to just wire it out to the border of the next structure and thus ignore it. If you are interested in the error and e.g. need to influence downstream code based on it, you need to handle it, of course.

[Dhakkan]

I'm going to offer up a slightly different take here, loosely based on MQTT's QoS - quality of service. (Link here, if you're not familiar with it - I suggest reading that content first.)

In essence, your decision to wire through the error would be based on the QoS desired for that message. Some of your messages may be enough to fire-and-forget (QoS0) like the broadcast messages. Others may be critical in that you only want that message sent-and-delivered exactly once (Qos2). Yet, others may fall somewhere in between Qos1-ish.

[Shiv0921]

Thanks all for keeping me on the straight and narrow. 

In this program I'm referring to the sender not requiring anything from the receiver, it sends commands but if the receiver has failed due to a hardware issue our program can continue as we'd still like the data from the rest of the branches, none of which depend on eachother.

However I can see that this is specific behaviour for this controller module, and I hadn't been thinking of scenarios where the caller might require the nested alive in order to be able to carry out its own job. 

I agree that any design idea that goes 'this is fine so long as I also remember to do this (aka catch the original error)' is a smell, because I or another developer might miss doing that and so it all comes crashing down. So thanks, that should have been my first hint.

Given we still want this capability I think I'll change the batch messaging, putting in something in that keeps track of which modules are alive and only sends to those.  

On reflection I see how messing with your awareness of what's alive in your system is quite a serious thing to do, so thanks everyone for reminding me of that!