LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
prettypwnie

Make "Automatic Error Handling" actually work!

Status: New

TLDR: LabVIEW should be able to throw and catch exceptions like other languages.

 

I'll start by saying that I always leave automatic error handling turned on - please don't hate me! Yes, I am a CLA, and maybe I'm the only CLA in the world that does this - but I firmly believe that if there is an unhandled error out there in my code, I want to know about it! I don't want it to pop up in production of course, but in development the automatic error handling lets me know about any mistakes I have so that I can handle those errors properly.

 

Now - this led me to an even crazier idea. What if there was a way we could turn automatic error handling into a full feature that could not only help during development, but also be used in production.

 

Other programming languages have the concept of an "exception" which you need to "catch" to handle it properly. The idea is that throwing an exception is better than returning a value that indicates an error because then you have to rely on the person using the function to remember to check that output - but the exception will pop out at them and so they'll realize they need to handle it.

 

Okay so here's the idea for LabVIEW: If the automatic error handling catches an error that isn't wired out, that should be an event that programmers can "catch", either in a normal event structure or some kind of special new error event structure. That way, we can choose what behavior we want for an unhandled error (instead of the default NI dialog box), eg: maybe we just want to log it to file, maybe we want to display it in a smaller window, or handle it in some other way, depending on the application.

10 Comments
ChrisLudwig
Member

I like your standardized error event idea.

 

I have less experience with other languages, but I would love to see a build spec tab dedicated to error handling to easily switch the behavior for an entire project at the build.  I like the idea of having options including:

  • the legacy automatic error handling for those that want that behavior
  • no automatic error handling
  • logging errors to file with a standard naming convention (build name and date/time probably) and default file location in the build spec and a method that allows the developer to specify an alternate location and file name programmatically at runtime (of course error reporting to disk would have to be done in a safe manner, with buffering by a queue or similar so the file write does not delay time critical processing, and repeat identical errors are not repeatedly logged to file)
  • reporting of errors through a global collector as you suggest, an event or something similar.  LabVIEW should ship out of box with an error reporter window similar to MGI's markdown logger panel that would monitor the global collector and launch on new errors or when opened by the user (behavior definable programmatically).  I'm not sure that the ability to see multiple error files in one window is needed, but I love the readability of MGI's markdown formatted error log.  I would add the "possible reason(s)" if possible to the error log though.  That is often helpful.

MGI's Markdown Logger Panel:

ChrisLudwig_0-1628180114424.png

 

Once we solve this, we need to write an idea to script better error handling in actors.  I hate that actors stop on errors out of box.  Handle Error.vi should not have to be overridden except in very unusual circumstances.  Maybe that is just me though.

AristosQueue (NI)
NI Employee (retired)

I spent two years working on this (2012-2013). It's a good starting point for an idea, but "just do exceptions" doesn't work. There are two main problems:

 

1. What happens in *parallel* branches of the same VI when exception throws in another branch?

2. What is the behavior of VIs that execute even on error?

 

You propose an event structure for catching. That's a good start for brainstorming, but it cannot address those two issues. The event structure idea was explored. Part of the discussion for question #2 went something like this:

"Well, just ban Close Reference from being inside the structure."

"Sure, but what if Close Reference is inside a subVI."

"Ban the subVI."

"That means we would need to know as part of a VI's conpane that this is a caller of Close Reference. So adding a Close Reference node becomes a breaking change for Call By Reference nodes?"

"Ban the Call By Reference node from the event structure?"

"Ug."

 

At the end of the day, "throw an exception" turned out not to be compatible with dataflow in many ways... but "flow an exception" can be. 🙂 We realized that if we rephrased "I want to throw exceptions" as "I want a way of automating the routing of errors and standardizing the responses of nodes to be able to eliminate the very tedious (and often incorrect) error wiring done today" that we made a lot more progress to a viable solution.

 

The end result of two years of work is a report on a very different error mechanism, but one that allows each VI to opt in or out individually with full interoperability with existing VIs, so users don't have an all-or-nothing adoption for exceptions. We didn't find any lesser mechanism for improving the current situation without breaking compatibility with all existing VIs, and that would be a non-starter.

 

Given the scale of the project, I think it is a good idea, but it is way back on the backlog. It's hard to get kudos for a project like this because so many customers don't even realize how much of a time sink the error wiring is, and they don't really see it as an area for improvement. I hope someday it bubbles up.

AristosQueue (NI)
NI Employee (retired)

Chris Ludwig wrote:

> I hate that actors stop on errors out of box.

> Handle Error.vi should not have to be overridden except

> in very unusual circumstances.

 

I absolutely disagree with statement 1. But I agree heavily with statement 2. What are you doing that you have to override Handle Error commonly? Never mind... don't answer that here. Move that conversation over to https://ni.com/actorframework🙂

AristosQueue (NI)
NI Employee (retired)

Here's one fun diagram we debated a lot.

 

AristosQueue_1-1628183159970.png

 

ChrisLudwig
Member

If that VI threw an error, then it should not be outputting a usable index (so probably -1), but unfortunately it is probably outputting the default value for the data type, 0, which will close the wrong ref.  In this case, and I'd say in all cases, the developer is responsible for managing how exceptions are handled in downstream code.  In that case (in all cases?), they should be using case structures to decide what portion of downstream code is executed.

 

I don't think we are asking to change the error handling paradigm, just the error reporting paradigm.  It is still up to the developer to catch and handle errors in the data flow as needed.  What would be nice is if LV supported a general error reporting system without having to resort to all the third party reporting solutions which are all based on dropping error reporting vis all over the various block diagrams.

 

AristosQueue (NI)
NI Employee (retired)

> I don't think we are asking to change the error handling paradigm,

 

I know for a fact that most of the users who have asked me for this feature over the last decade are asking to change the error handling paradigm -- they send me MS Paint diagrams in email or draw them on napkins during NIWeek lunches!  But even if you're not, the error handling mechanism has to shift at least some to make an error reporting mechanism useful. How far it has to shift is part of the debate.

> What would be nice is if LV supported a general error reporting system

> without having to resort to all the third party reporting solutions which

> are all based on dropping error reporting vis all over the various block

> diagrams.

 

What is an error and when should it be reported to such systems? If you try to trap every thrown exception in most C++ programs -- which you can do -- you will quickly turn it back off because tons of low level functions error out and are immediately handled by the caller. You don't want that information going to a global log because it is "below the scope" of the global log. Automating that is, in my opinion, not an option. What we can do as a language is standardize how that reporting is instrumented and standardize the packaging of error management code.

prettypwnie
Active Participant

I feel very honored that AQ responded to my idea. I do get what you mean, that things can start getting complicated very quickly as we go down the road of this idea. I would love it if NI can keep this on their radar - even if it's not this idea exactly, it would be amazing to have a better way to deal with errors.

AristosQueue (NI)
NI Employee (retired)

> it would be amazing to have a better way to deal with errors.

 

Now THAT is a sentiment I DEFINITELY agree with.

wiebe@CARYA
Knight of NI

The multiple errors (Dialog & User Interface>Multiple Errors palette) is a great improvement. The trick is to right click merge errors to make it merge errors (Retain All Errors).

 

In a way, this enables 'collecting' errors from loops. I use it for this, and to 'annotate' the raw errors with useful information.

 

An error dialog is pretty easy to make. Mine simply adds errors to the existing dialog if it's opened already. Closing the dialog clears the errors.

Petru_Tarabuta
Active Participant

1. For an excellent discussion of how throwing exceptions in LabVIEW could or should look like, and the benefits that exceptions would offer, please see the LabVIEW Exceptions: a paradigm shift to error handling in LabVIEW presentation that Nate Moehring delivered at the CLA Summit 2010: https://www.themoehrings.com/index.php/2010/12/labview-exceptions-a-paradigm-shift-to-error-handling... 

Petru_Tarabuta_0-1725131289345.png

The direct link to the PDF slides: https://www.themoehrings.com/wp-content/uploads/2010/12/LabVIEW-Exceptions.pdf 


2. People who like this idea might also like to kudo the following somewhat related idea: Custom automatic error handling callback .