Try catch structure

[Tushar_Jambhekar]

Currently errors can be connected to the case structure and appropriate case can be executed.

Many languages do error handling with try catch type of code, I think a structure like it would be much more efficient than propagating errors.

normally code will start execution from code case, if any error occurs then it will immidiately switch to error case, and irrespective of error occurance finalyy case would be executed in the end.

[AristosQueue (NI)]

This idea needs more input from the community before it can even be contemplated. There have been several attempts to design a try-catch-finally structure for LV over the years, but all of the mechanism proposed thus far has been unsastisfactory.

There are many semantic and implementation issues. Here's one key issue:

If I have two parallel code segments inside my Try statement and one of them throws an exception, what is the behavior of LV? An exception throw works because it unrolls the call stack for the local thread. It cannot message other threads. Should LV add mechanisms to stop the parallel threads? Should the parallel threads run to completion but then throw away their work at the border of the try? What about if the other thread is busy calling a subVI -- does it abort the subVIs?

Please post further details about how you would want this feature to behave, including what you think should happen if an exception is thrown and is not caught, and how you would specify which exceptions to catch (users could just specify error code or LV might create "classes" of error codes --- what would that look like?).

I do understand the desire to remove error wires from your LV app, but the devil is in the details. This would be an idea I would love to see move forward, but it cannot without more user feedback.

[Tushar_Jambhekar]

yes i understand.

Let me explain in bit detail what i really wanted when i suggested this.

for long time i am striving to make error handling automatic/Configurable and perfect to the extent it can be.

The first effort was to create some tool which would make error handling more configurable. and result was published here

http://forums.ni.com/t5/LabVIEW/General-purpose-Error-Handler-Routines/m-p/455908

It helped me a lot in the beginning and life was much easier. but there were two issues.

1. It was completely flow based and event supoort was minimal.

2. Even though we can specify error handling (or error recovery) module, i found that it was not at all effective.

In second attempt i added error event generation and modified queued state machine architecture so that i can notify the occurance of errors. this helped me to

1. notifying errors of one layer to other layer

2. Implement centralized error handlers

3. do better level of error recovery

However i am missing that "Finally" part. in "try catch" if exception occurs then finally clause executes AFTER error handling... and thats very important for me.

I understand the problems you have mentioned. I will think on my ideas more and write back again

[Darren]

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.