Allow Error Case Structure to Handle Specific Error Numbers

[Hueter]

When you connect the error wire to a case structure selector, you get two cases for error and no error. I think you should be able to add in cases for specific error numbers so you can handle specific errors differently. You could do this currently, but you would have to unbundle the error and use the error code.

[AristosQueue (NI)]

Muks: I wouldn't want a dialog to display the source directly -- that is not necessarily well formatted information. That's the reason that the General Error Handler exists. At the very least, I would pass through the GEH with the "no dialog" option in order to get the message string.

[gerh]

---

@AristosQueue (NI) wrote:

gerh: Generally I like the proposal, but I wonder if you have any thoughts on how to differentiate those frames via something other than color. I already hear complaints about red/green on the error case as it stands from color blind folks. You have some pretty subtle shading in your current picture. Can you propose anything to differentiate the border by pattern that wouldn't disrupt your reading of the diagram?

---

Distinguish by the header line.

---

@AristosQueue (NI) wrote:

What if we didn't do any new color differentiation at all? Green for the no error case (even if it had other errors in the same case) and red for all the others, regardless of the error/warning mix?

---

Just to remind: colour blind people can't distinguish between red and green, but they can see other colours like yellow or brown. So the most frames will look the same, no matter if there are many different colours or just two. But this is an entirely different discussion which addresses many other things throughout the whole Labview environment either.

The differetiating between border colours should just simplify the handling of different cases. At a closer look there is no need for colours, because the header of the frame carries all informations somebody needs. I don't prefer the two colour solution, because it's not clear which colour fits to a mix of "No Error" and "Error", so I chose the brown frame for all mixed cases.

Different border patterns are made to distinguish between different functionality like a case structure or a while loop. So I don't think it's a good idea to introduce this dependent on the value. See the Event Structure as example, there is also no different pattern dependent on the event source or it's value.

---

@AristosQueue (NI) wrote:

Also, I would expect people to want a frame that handles both one specific error and no error -- that would crop up when trying to filter one error out but report all other errors. Similarly, one frame for no error and a warning, and for no error and an error and a warning.

---

Maybe I didn't understand that question properly, but I can't see any problem.

First case (examle error is 12345): "a frame that handles both one specific error and no error"

Enter "No Error, Error 12345" into the frame. (brown frame)

Second case (error to leave out is 12345): "filter one error out but report all other errors."

Enter "Error ..12344, Error 12346.." (red frame)

Third case: "one frame for no error and a warning"

Enter "No Error, Warning"

Fourth case (example with error/warning 12345): "no error and an error and a warning"

Doesn't make sense for generic errors and warnings because this would match for everything, so I assumed there is at least one specific error or warning.

With specific error: Enter "No Error, Warning, Error 12345" (brown frame)

Same with a specific warning: "No Error, Warning 12345, Error" (also brown frame)

OK... I just forgot the case "No Error" in the pulldown menu of the editor.

Just to explain: the idea behind the "Error+Warning" case (orange frame) is to have a frame which uses only the "code" and is blind to the "status" value of the error cluster. If entered as "Error 123, Warning 123" the IDE should correct that automatically to "Error+Warning 123".

Edit: One more detail I haven't considered previously: One of the frames should be assigned as "Default" case, similiar to the other numeric based case structures. Otherwise there may remain unhandled cases which break the program.

[tyale]

Any update on this idea?  It is fantastic and a much needed improvement to LabVIEW's error handling.

[Darren]

Available in LabVIEW 2019 and later. You can now specify one or more error frames on an Error case structure, and use numeric ranges in those frames for ranges of error code values in the error cluster.

[wiebe@CARYA]

This seems related:

https://forums.ni.com/t5/LabVIEW/LabVIEW2019-case-structure-with-wired-error-cluster-changes/td-p/39...

If he's right, that doesn't seem desirable.

[AristosQueue (NI)]

@Weibe -- we found the problem... the guy is using an unpublished, rusty nails config token. We didn't check that code path. That's a dangers of using unsupported config tokens. We're probably going to remove the config token entirely (or we may leave it, but we'll isolate it more in the code base... if it is easy to leave, we'll probably do that since at least one customer finds it useful as a color-blind accommodation).

[Darren]

I posted more details (including a CAR number) on the forums thread: https://forums.ni.com/t5/LabVIEW/LabVIEW2019-case-structure-with-wired-error-cluster-changes/td-p/39...

[wiebe@CARYA]

@AQ

Thanks, glad it was something obscure. I'd imagined that key would effect only cosmetics, but apparently it's a bit more.

As it is now (<19), the Boolean is used for case structures. That means there can be an error 0. Am I correct that this changed? Or can this still be used (e.g. when no specific numbers are given)?

Does this also mean that Boolean operators on errors (still acting on the Boolean I presume) can handle errors as true, but the structure doesn't?

It is of course unwise to depend on a 0 error, but if it's a change it would be good to know in advance.