LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
tarheels100

Require that VIs declare/list all errors that they can throw

In Java, any errors/exceptions that a function can throw (to its caller) are listed directly in its signature/declaration.  This would be nice functionality to have in LabVIEW.  Otherwise, the only way to determine which errors a VI can return is to either:

  • examine the code manually, recursing through all its subVIs or
  • brute-force exercise the VI until you have observed all errors that it might throw in your particular application. 

Neither of these options seems particularly robust or efficient.

 

It may even be possible for LabVIEW to determine the throwable errors automatically, although at least having the ability to declare them manually would be a good start.  They could be registered through the development environment such that they are stored in the VI file itself.  In this way LabVIEW could summarize all the errors a given VI throws based on those declared within it and its subVIs. I acknowledge that this would likely require a more sophisticated error system than the current error codes (since these may not be known at compile time).  But, I would be surprised if it couldn't be achieved in a similar fashion to Java where all errors are classes that inherit from a common "error" class.

 

If I'm missing some methodical, pragmatic approach for achieving the same result, please let me know.

9 Comments
crossrulz
Knight of NI

Duplicate: List every error code a function can give out!


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
tarheels100
Member

In response to @crossrulz asserting that this is a duplicate:

 

While I understand that related questions/suggestions have been posted before, I want to point out a couple differences with what I am suggesting, particularly in the implementation I've recommended.  In my assessment, the question that you link to is requesting additional documentation for built-in LabVIEW functions to specify which error codes they can produce.  The answers assert that this would be unmanageable from a maintenance perspective, which I'll accept (especially since it sounds like this was attempted at one time).  In contrast, what I'm requesting is an additional feature to ease the process of users documenting, managing, and handling errors in their own code (although the feature could be also used internally for built-in LabVIEW VIs as well).  I'm reasonably confident that the method of declaring throwable errors per VI is feasible given that this approach is used in other languages as a matter of course, as in Java.  To expand on my original post, I suggest two possible implementations: one simpler and the other more involved but also more powerful.

 

Traditional implementation

In the simplest implementation, the user could declare in the VI properties which errors the VI is able to produce.  LabVIEW could then automatically (and recursively) add to this list all of the errors declared within the VI's subVIs.  The errors could be declared as simple "code + source" pairs.  This implementation could fit fairly seamlessly in the current LabVIEW error system.

 

Object-oriented implementation

A more powerful implementation would be to introduce error objects that all inherit from a common error class, as in some object-oriented languages.  This would be a fairly disruptive change since it would do away with (or at least obviate) error codes and the familiar error clusters, but I still want to put it out there as an option since it could greatly benefit LabVIEW developers.  One advantage is easier maintenance since errors are declared/specified based on their class name rather than an arbitrary number code.  Since all errors are object that are known at compile time, the LabVIEW IDE could easily determine which errors a VI could throw, removing any need to even document them manually.

 

Lastly, I'll do some more searching to see if I've missed some existing method, but I want to emphasize that this request is based on a real fundamental question: how can I make robust code that consistently handles all possible errors coming from a wide range of sources (e.g., built-in VIs, hardware SDK VIs, my own libraries, etc)?

Intaris
Proven Zealot

I think what you propose is precisely what cannot reliably be done.

 

I don't think there is any misunderstanding here.

tarheels100
Member

@

 

Intaris
Proven Zealot

It's the bit "reports back all such declared error codes" that is the problem, not the moethod of correlating such codes.

AristosQueue (NI)
NI Employee (retired)

tarheels100:

My previous comments on the duplicate idea discussed the JAVA nightmare. Checked exceptions mean that your code breaks when you add a new exception, which means no one ever adds a new error, so they end up re-using the same errors for completely random situations just to avoid breaking changes. Not something I want to bring to G. Other modern languages have eschewed the JAVA model. As far as I've heard, most JAVA libraries these days just use "throws" without specifying what they throw, but that's just rumor I've heard.

 

Checked exceptions also only work when you can be certain that the exceptions are propagated by the language. But in LV, the wires might not propagate all the way to the "error out". Or they might come through a queue or channel or other communications mechanism. Or some number known only at runtime from a DLL might be bundled in. So the compiler cannot check the declarations. That means it is turned right back into the documentation problem.

 

> A more powerful implementation would be to introduce error objects that

> all inherit from a common error class, as in some object-oriented languages.

 

Speaking as someone who has built that hierarchy (somewhere there's a presentation circa 2012 that I gave at CLA Summits about it), it doesn't help the problem. The output terminal is still generic error type (because it has to be able to return "no error" unless your VI is an error generator), and so you're right back to declaring. And error objects still propagate as data, not as language escalations, so values still appear on the diagram through other means.

 

It's a nice dream, but I don't see it ever becoming a reality. APIs are just too fragile with checked exceptions.

Darren
Proven Zealot
tarheels100
Member

@

 

 

from (and much more limited than) my original request here.

AristosQueue (NI)
NI Employee (retired)

I really hate being such a downer in this area. It's something I wish could be improved, but I have yet to hear something that doesn't have more downsides.