error source includes case name

[zou]

If an error occurred inside a case/event structure, it should include the case/event name in the error source for easy tracking.

It'll save tons of time for large applications with a lot of cases in the process loop.

I know I can do it myself.  Just something better to have with a right click.

[X.]

How would that work? If there is an error produced in the case, it will (hopefully) have a source message in it. If there is no error, obviously there is no need for a message.

As you said, there are simple solutions to your request:

[AristosQueue (NI)]

I'm not saying this is a bad idea. I'd certainly like that info. But I think it is technically impossible to achieve without seriously crippling LabVIEW run time performance.

Let's assume we only did this in the place where the error was generated -- i.e., the same place that the call chain is stored off, we inserted along the call chain frames of case structures.

I have no idea how we would accomplish this. The LabVIEW run time engine knows nothing about the block diagram. Literally, nothing. There's no place to store off such call information during compile into the generated code. Even if there were (let's assume there is), the performance impact would be huge, recording in every thread when it entered and exited every case structure so that it can be retrieved by whatever deep subVI happens to generate an error.

Frankly, this seems like a technical hurdle that isn't surmountable -- like, as in, give me infinite resources, I don't think it can be solved. Anyone want to propose a way to track this information in the runtime engine in any sort of sane manner?

[donkdonk]

I have a use case myself. In our template -where we use the JKI state machine- I implemented a vi (provided by GPower) that adds exactly this info to the error source.

For me it has been very helpful to know which state causes the error (if any).

I would use this feature once implemented, but I think it makes the error cluster in combination with the case structure special and how would you know about this feature?

Anyhow, AristosQueue already pointed out it cannot be done.

[crossrulz]

donkdonk wrote: For me it has been very helpful to know which state causes the error (if any).

That is why I have special code to call my error handling state when there is an error.  Part of that code keeps track of the last state called.  Therefore my error handler reports which state caused the error.

[zou]

@X. Would it be great if you can right click the output of error cluster and select includes case name, just like the auto index ?

Your implement is project dependent, and doesn't work for event structure.

@AristosQueue:

If X can, I don't know why you can't.

User should select this option at edit time, just like the For-loop auto index.

Don't understand your argument about runtime.

[X.]

[AristosQueue (NI)]

If you can do it, we should be able to do it, but I had no idea how you're doing it. Now, I see X's code and I'm much less interested in this idea.

a) You're just tacking onto the end of the source information.

        1) That means you're not inserting this information into the right place in the call chain that is already embedded in the error source string. Doesn't strike me as particularly useful.

        2) That means you may be adding to the embedded <err> or <append> information that is already in the source string. Modifying the source string like that is not a well-defined operation.

b) This only works for one case structure. What about when there are multiple case structures on the same VI or a caller VI? If you aren't embedding all of the call chain info, this is not nearly so useful.

I'm glad that you all find this to be a useful thing sometimes in your own code, but speaking as LV R&D, it is unsafe and not generalizable. Speaking for myself, I don't see that it adds anything useful to the debugging when it is such partial data.

No kudos from me.

[X.]

I am just making this all up as I am also trying to better understand the ins and outs (pun intended) of this idea...

[AristosQueue (NI)]

X: Ah. So this isn't a VI that you use yourself. Thank you for clarifying.

Zou wrote:

> Don't understand your argument about runtime.

A request to turn the option on would be done at edit time, but the actual adding of the case structure name to the call chain would have to be done at run time *at the place where the error is generated*, even if that place was several subVIs down and through multiple case structures along the way.

You say you can do this today. Can you post your VI so we know exactly what it is you're doing? We may be talking past each other.

[cyro]

You can use the boolean of the error as data. Boolean is 8-bit and error is value greater than 0 so you should be able to set the first 255 cases of your structure in the error cluster. Problem is case "0" so better set enum "0" to "nothing" or something like that.