LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
P@Anand

Easy Error Handling while debugging.

Status: New

While debugging my application I became curious that if an easy way finding the error is available how the things will be. Am not sure somebody has proposed it already, am giving my suggestion. The VI can have the option of pausing it when an error occurs anywhere in that VI.

 

Error Handling.png

 

 

I guess this would help us much better way of debugging an application.

-----

The best solution is the one you find it by yourself
12 Comments
tst
Knight of NI Knight of NI
Knight of NI

There are two separate ways of doing something similar today:

 

  1. The automatic error handling checkbox will pause the VI if the error output is unwired, but relying on that is bad style. Error out terminals should usually be wired and handled.
  2. You can place a conditional error probe on each specific wire and set it to pause if there's an error. This is generally fine for me, because if there are errors I usually know where to look for them.

 

This suggestion does have a certain appeal, but it's also something which makes me somewhat uncomfortable, because it feels as if it would come in the place of actual error handling.


___________________
Try to take over the world!
P@Anand
Trusted Enthusiast

I do know the way of finding the error that you have explained and I was using that.. But that too is a pain when you are debugging a big application which is not developed by you.. Am doing that and that made me write the idea...

-----

The best solution is the one you find it by yourself
AristosQueue (NI)
NI Employee (retired)

KUDOS FOR THIS IDEA. I can't tell you how many times I have gone through my VI hierarchy and deleted all of my error wires just so I can get automatic error handling to trap the error at the point of generation. It's particularly useful in apps with asynchronous VIs where the VI may not be in memory when you start (so you can't drop a probe) or with reentrant VIs where you don't know which clone will have the problem on any given execution (so you again can't drop a probe).

 

I wouldn't use it to replace Automatic Error Handling -- that's a good separate option for people who forget to wire an error, at least during development.

kegghead
Member
Oh yes. When programming in C one very useful feature is to break when an exception is thrown. This would be the LabVIEW equivalent which I miss every time I need to debug an error whose source is unknown.
kegghead
Member
Come to think of it, I think this would be better as a project scoped setting rather than a specific VI. Or if it is attached to a VI, have the setting inherit to all children in the call chain which have accessible diagrams?
Broken_Arrow
Active Participant

KUDO, but I wouldn't want it as a permanent part of the VI's execution properties. How would this effect the EXE? But still, kudos for the idea to get thinking of this feature somehow, somewhere.

Richard






tst
Knight of NI Knight of NI
Knight of NI

Like I said, this idea does have some appeal (particularly for the use case of debugging someone else's code), but there are things which need to be addressed. For example:

 

  1. Some errors are perfectly legitimate (such as timeout errors in communication) and I wouldn't want my code to break for them. How would that be handled? You could probably set up a filter saying "ignore codes A, B and C", but I'm not sure that would be enough.
  2. What happens if you have VIs chained with an error cluster and an error occurs somewhere in the middle? Would LV break at each error out terminal? Ideally, it would probably have to recognize this chain and only break on the first occurence of the error.
  3. What happens with an error inside a locked VI?
  4. ?.  I'm sure there is something.

 

Broken Arrow, such a setting would be ignored in an EXE, just like the auto error handling is ignored. It's a debug feature.

 

AQ, I agree with you that the way the error cluster currently works makes finding the source of the error difficult, but I don't think this solution is a good one for that. Ideally, I would have liked the source string of the error cluster (or whatever method will replace it at some point) to have more details about the source.

 

For example, instead of just saying "an error occured at property node in VI X" (sometimes with the addition of some details, such as which argument index it was), it should say "an error occured at property node A (LV would obviously need some way of identifying it) in VI B. The error was at property C and the input value was D".

 

This level of detail should ideally also be available in executables, which is one considerable improvement over this idea. Obviously, implementing such a system is much more complicated than implementing this idea.


___________________
Try to take over the world!
P@Anand
Trusted Enthusiast

I Agree with your Point 1 that the VI should not break at the time out error point at those cases we can add an exception because we will not be using these type of functions in a large number and for those cases we can add an exception (Like we have the "Exclude from Diagram cleanup" option) and can easily get the place of occurrence of error.

 

Fort point 2 as you said it should obviously pause at the 1st occurrence of the error.

 

For the Locked VI we do not have to bother about it. If the error is occurring at the locked VI then identify that VI and try replacing as depending on the application or the developer has to take care of it but our point is we have identified that error.

 

The point you have given would be better but logically when an error is occurred and the VI is paused then we got the direct point of error instead waiting for the error message we can handle that.

-----

The best solution is the one you find it by yourself
தமிழ்நேரம்
Member

Related Idea:

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Pause-on-first-Error-option-for-debugging/idi-p/175159...

 

Wondering if we can merge the count on kudos?

            These two ideas talks almost about the same but in different posts. so I am wondering if we can merge the kudos and bring the feature in next LabVIEW.

 

அன்புடன்
தமிழ் நேரம்
முதல் இந்திய ஆய்வுமெகபொப சிற்பி
சோதனைநிறுத்தம் சிற்பி
மற்ற சான்றிதழ்கள்
யாதும் ஊரே! யாவரும் கேளிர்!!

P@Anand
Trusted Enthusiast
I posted before the other post was made but my idea got very less Kudos than the later one. What I am missing here? 😞
-----

The best solution is the one you find it by yourself