How would you redesign the LV error cluster?

[ShaunR]

I think we both chose avatars that fit our personalities nicely

Touche

[OlivierL]

I find this thread quite interesting as this is a good problem that we have all been facing for a long time.  Our team did some research last year to try to create a unified error handler similar to the SEH that would meet all of our requirements but in the end, after testing a few different flavors, we chose to integrate our error handling as a separate state in our templates.  We do this in a very similar way that JKI State machines template but we include a few more parameters such as which case was the error generated in (to facilitate debugging) as well as automatic logging and display in a non blocking manner.  Based on the error code, we can either let a default behavior programmed in a Sub VI or override the handling of any specific code or range of error codes on a "per code module" basis.  We could not find any other way that would offer us the flexibility and reliability that we need in our projects.  We find that by including it in this way, as part of our template, our developers were much more inclined to add the proper error handling code as it was easy to do so.  Moreover, that specific code is visible on the BD (not hidden in an Express VI.)

With this approach, it is easier to handle specific errors in each module/driver and it is almost "synchronous" (in between each cases).  This seems to be better than generating an event when an error occurred which would still only be handled when your code gets back to the event structure.  As for the format, we find that the current cluster offers enough information even though the default "tags" in the Source element are not obvious at first.  

The idea of objects and more complex error handler built in a smarter subVI is nice but we have given up on finding the silver bullet and went for a practical approach that work well in our code.  We'll definitely keep our eyes open in case something better comes around...

[Stobber]

Our team did some research last year to try to create a unified error handler similar to the SEH...but in the end...we chose to integrate our error handling as a separate state in our templates... We could not find any other way that would offer us the flexibility and reliability that we need in our projects.  We find that by including it in this way, as part of our template, our developers were much more inclined to add the proper error handling code as it was easy to do so.  Moreover, that specific code is visible on the BD (not hidden in an Express VI.)

With this approach, it is easier to handle specific errors in each module/driver and it is almost "synchronous" (in between each cases).  This seems to be better than generating an event when an error occurred which would still only be handled when your code gets back to the event structure.

The idea of objects and more complex error handler built in a smarter subVI is nice but we have given up on finding the silver bullet and went for a practical approach that work well in our code.

 

Sounds like you made the same discoveries I did through field testing! A FSM executes state-check logic on every "clock tick", so it's still synchronous error handling. I suspect you're usually aborting normal logic downstream of an error and letting your "error case" do its work before executing the intended logic again or changing state and executing other logic. This all follows what I think is the only realistic way to address errors in LV run-time logic: deal with them as close to the code that threw them as possible, so you have the "context" of that code available to your handler. And yes, providing a template for handling -- along with maybe a couple of very common generic handlers that get used all over, like "log and clear" -- is the only realistic way to spread error handling know-how to an entire team. Each handler has to be (at least somewhat) custom, so you can't reasonably expect to create an all-purpose error handler for direct reuse.

[hooovahh]

Sorry to answer an off topic question but I found more information on a comment.

Where's the thousands of events to choose from in the event structure (maximise, minimise, open etc)..

I just learned of a way to get an event generated on minimize or maximize. You can then choose to not update the UI if you have lots of power updating it.

The event window resize is generated on minimize. You can then use the property node on the VI to get the front panel state. It has the previous state in the event but not new state for some reason.

[OlivierL]

Sounds like you made the same discoveries I did through field testing! A FSM executes state-check logic on every "clock tick", so it's still synchronous error handling. I suspect you're usually aborting normal logic downstream of an error and letting your "error case" do its work before executing the intended logic again or changing state and executing other logic. This all follows what I think is the only realistic way to address errors in LV run-time logic: deal with them as close to the code that threw them as possible, so you have the "context" of that code available to your handler. And yes, providing a template for handling -- along with maybe a couple of very common generic handlers that get used all over, like "log and clear" -- is the only realistic way to spread error handling know-how to an entire team. Each handler has to be (at least somewhat) custom, so you can't reasonably expect to create an all-purpose error handler for direct reuse.

 

Yes, your assumptions are correct.  Our Sub VIs have standard Error handling (case structure) so not much more happens until the current case completes and the error handling case executes on the next iteration of the While loop.  From there, we can either attempt a recovery, ignore it or request the main application to restart or to shut down safely.

 

One thing I mentioned and strongly recommend to others is to include the case where the error was generated when reporting the error.  It made our life a lot easier when we added that information instead of simply offering the name of the VI where the error occurred.  Another nice thing when debugging is that you can still put a break point in the error case and quickly backtrack to the faulty case (assuming Retain Wire Value is enabled...) and understand what happened.

 

It's nice that we came to similar conclusions but I would be interested in hearing from others who do things differently.

[Argold]

To give this thread a bump, and to redirect the discussion to a different thread:

I have been commenting recently on an old 2009 thread that was the result of a 2009 NI week presentation.  The thread had some good code examples and a video of the presentation and some slides.  I'm working through that all to understand it and possible continue the work.

There was a nod to this thread in an earlier post:

Unfortunately "Handling Core" is a bit of a misnomer, because the code was not about error handling but a means to carry multiple errors or much more error info (such as priority and severity) in errors.  One method used OO-in-Native Error Clusters (NEC) and allowed for special error classes, The other allowed for multiple errors to be carried by putting NEC into OO.  A suggestion in the thread suggested both: NEC-in-OO-in-NEC.  and that is where I'm thinking of taking it.  The beauty of this is that it "may" be able to coexist with NEC alone, which would keep the overhead down as it would only be used where needed.

Anyway, go on over there and see what I mean, this may be some valuable stuff.

-Allen

[Argold]

I just posted my take at updating the error handling core on:

https://lavag.org/topic/10741-updating-the-labview-error-handling-core/

I can cross-post here if there is any interest.

-Allen