Error and Exception Handling

[Fire]

Imagine you develop an VI that generates serious errors and you would like to force a calling VI to handle them. This ist not possible is the current and previous versions of LabVIEW.

Typically a library VI does not know how to recover or to handle the errors. The calling VI has the responsibility to handle such subVI errors or to propagate them to its caller.

The following VI snippet shows the idea of the error handler structure. I am using this work-around to imitate a try-catch mechanism, but still missing the complete list of possible errors  of subVIs.

 

The calling VI needs to know all possible errors/exception that can be thrown by a subVI. At the moment a develeoper has to check the blockdiagram, VI description or manual to get this information. From my point of view this error/exception information must be part of the VI's public interface.

So, I propose an additional category in the VI Properties dialog: "Exceptions" and a "try{...} catch(exception){...}" programming structure.

- The Exceptions category should contain the list of possible exception that can be filled by the developer, Error/Warning code, description etc. Additionally the developer should be able to pass data to the exception handler, e.g. similar to dynamic event dispatching to the event structure. Of course the corresponding data types need to be defined somewhere in the VIs public interface, e.g. typedefs(.ctl) or subclasses of a generic exception class.

- The "try{...} catch(exception){...}" programming structure could be designed similar to the event structure with dynamic events. The timeout case would correspond to the try-block, other cases implement the catch(exception)-blocks. Since exception are part of the VI's public interface, possible exceptions coud be selected from an context menue that contains all possible exceptions of all subVIs in the try-case. All exceptions not handled here will be propagated to the calling VI. Of course this unhandled exception become automatically inserted in the exception list of the exception-category of its VI-Properties.

- Missing exception handling when using subVIs that have defined exceptions will break the VI Run-button.

I think it is absolute necessary to become able to force a subVI user to deal with possible exceptions. At least all VIs contained in vi.lib should have at least an explicite error list in its VI Properties as part of their public interface.

What's your opinion?

Regards Holger

[AristosQueue (NI)]

Jeff Kodosky, inventer of LabVIEW and continuing genius contributor to LV, had a number of us work on the idea of try/catch a couple years ago. None of the variations we tried came out any where near as good as the error code cluster propagation that we have today. Jeff continues to work on variations in that direction, but most of us have given up on the concept.

Let me just throw out one of the problems, as an example of why the concept doesn't work so well:

• > - Missing exception handling when using subVIs that
  > have defined exceptions will break the VI Run-button.
  
  Ok, suppose a subVI is capable of returning one of these "caller must handle this" errors. Does the caller have to handle the error as soon as the subVI call is made? In other words, does this error handling structure have to go around every individual subVI call? 
  1. If you answer "yes": What if the caller VI cannot handle the error and has to give it to its caller? Do you force the entire contents of the rest of the caller VI to be in a case structure, with one frame being empty and the other being the rest of the caller VI contents? If no further code is allowed other than "do nothing so you can return" or "handle the error", how do you have any code to format data for the error? Do you create complex restrictions on which nodes are usable in the error handling case?
  2. If you answer "no": What if the subVI call is in an infinite loop such that the caller VI never does finish? What if the caller VI goes ahead and does more work instead of handling the error immediately and triggers a second such error?
  I'm not looking for you to answer this question... my point is not to raise debate, but just to highlight one aspect where argument can go on for a long time.

> I think it is absolute necessary to become able to force

> a subVI user to deal with possible exceptions.

I disagree. A subVI should be able to return some form of error, but it should always be possible for the caller to ignore that. You were correct that a subVI doesn't know what its caller is doing -- that's why the subVI cannot do anything to handle the error itself. But because the subVI doesn't know what its caller is doing, it also cannot force requirements like this on the caller. 

What you can do is add parameters to the subVI that allow the subVI to handle the error, such as a path to a log file, or a reference to a VI that will be invoked if an error occurs, or something like that. 

> At least all VIs contained in vi.lib should have
at least an explicite

> error list in its VI Properties as part of their
public interface.

This is something you should probably file as a separate Idea Exchange submission. 

[Darren]

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