How can I implement try & catch in LabVIEW?

[iCat]

My boss wants me to implement a centralized error handling mechanism which shouldn't require attaching an error handler to every subVI that needs error handling.

C#, C++, and java have try and catch for this.

Can I do the similar with LabVIEW?

In other words, can I have a LabVIEW error handler catch every error caused without having to attach it to every subVI in big LabVIEW VIs?

[nathand]

Generally any non-trivial subVI should have error in and error out terminals, and VIs that may have side effects should not do anything if there is an error coming into the VI.  Then you chain together your VIs with the error wires, such that if an error occurs in one of them, none of the following VIs will execute.  That's a bit like throwing an exception - it interrupts the execution chain.  You then "catch" that exception by putting an error handler wherever necessary, but not necessarily in every single VI.  You wouldn't (I hope) put try..catch inside every single .NET function, instead you handle the exception at the level at which is is most appropriate.  Same thing in LabVIEW.

[iCat]

nethand //

What you've described is the method all of us have used so far.

This is inefficient compared to try {.. } catch if a VI is very very big.

If a VI is big, there can be dozens of ends of error wire chains, and it takes hours to find those ends and attach an error handler to them.

I want an error handler to catch errors without attaching it to any subVI or without having to attach it to all of the ends of error wire chains.

[RavensFan]

I really don't think it would take "hours" to find "dozens" of wire ends.

The only automatic error handling that occurs now is the popup dialog that occurs if you haven't handled an error.

What you could do is post your idea on the idea exchange and see if you can get some popular support for it.

[iCat]

Ravens Fan//

So you think I can't define an error handler that catches every unhandled error?

[nathand]

Unfortunately the best thing I can suggest is that you get in the habit of wiring the error wires all the time, so that you don't have lots of loose ends.  Of course this introduces dependencies, preventing VIs from running in parallel, but that's what you want - an error should prevent anything from happening downstream of it until the error is handled.  It sounds like you want your errors to be propagated "wirelessly" and there's no way to do that - errors need to be carried on wires.  There's no way to break out of a subVI when an error occurs short of putting the logic in place to do so.  Properly used, I don't see why this is less efficient than try...catch. 

I've worked on large projects and never had dozens of ends of error wire chains.  Do you have a huge while loop with dozens of things happening in parallel?  Any chance you can just throw in a merge errors at the end, so you only need a single error handler?  What sort of errors occur, and how do you need them to be handled?  If it's just alerting the user, merge errors could be enough.

[Darin.K]

I once had a half-baked idea that there would be an Error? Filter event for VIs which could act as a trap for unwired errors in front of the auto error handling dialog. Then I started shutting off AEH and forgot about it.

[RavensFan]

I think you can create your own error handler.  It depends on what types of errors you have and what kind of handling do you want to do.

I created an error handler which takes the error information and logs it to a file.  It is wrapped as a subVI which I put on the end of any given error wire run.  I also have an input that lets me wire in a string so I can identify the part of my code where it occurs such as "master state machine", "DAQ loop", "GUI Loop", ....

Other important things to do are as Nathan said.  Get into the habit of wiring up your error clusters.  If you have a subVI that you don't want to execute in the event of an error, put an error case structure inside of it so the real code only executes in the no error case.  You do all of those things, it doesn't take long to drop your error handling subVI at the ends of different lines of execution on the error wires.

If you have more complicated needs such as retry a certain action in the event of an error, or do something different that really only applies to one particular part of your code, then you may need a specific subVI you write to handle that rather than the general error handler.

It sounds like you are asking for a feature in the try/catch that would be more deeply embedded in the underlying LabVIEW language like an error handler that is smarter than just an annoying pop up that the automatic error handler gives you without specifically coding it into your VI's.  LabVIEW doesn't have that, and if you think it is worthwhile and others might agree, then post the idea on the LabVIEW exchange.  Personally,  I think the idea would be very difficult to implement, and as a programmer, I'd rather create my own error handling code that I can wire myself that is modified for each particular situation.

[SunshineDesign]

I like your idea Raven_Fan. I implemented exactly the same scheme and it works well and is easy and simple to implement. After all what I need is what error and where the error occured so I know where to look to fix the problem. It can also be used to determine the level of the error and if minor, clear and allow to continue, if severe then exit execution after reporting the problem to the error file.