Whether Automatic Error Handling (AEH) is enabled or disabled should be indicated on the block diagram

[Petru_Tarabuta]

Problem: When developing or inheriting a large code base it is helpful to know which VI has Automatic Error Handling (AEH) enabled and which has it disabled. Currently, the quickest way to get this information is to bring up the VI Properties window (pressing Ctrl + I) and navigate to the Execution page. This is tedious when done on large numbers of VIs.

Solution: LabVIEW should display whether AEH is enabled or disabled on the Block Diagram. For example, a grey triangle located in the bottom-right corner of the block diagram window could indicate that AEH is disabled, and an "error green" triangle could indicate that AEH is enabled, as seen in the screenshots below. This display method is just a suggestion - professional UX designers may well find a better method. I would be happy with any indication method that I could at a glance see on the block diagram window.

Idea expansion:

• Executing a single left click on the triangle (or any other indication method) would toggle the setting to its other value. For example, a single left click on the grey triangle would toggle the AEH to enabled and the triangle would become green.

[OneOfTheDans]

I'd prefer to see this on the Toolbar because it's a debug feature (like highlight execution), but generally agree it's useful to make the setting more available (vs. something more advanced like reentrancy, which should stay in properties).

[Petru_Tarabuta]

"I'd prefer to see this on the Toolbar" - I too would be happy if the visual indication was located in the toolbar.

"because it's a debug feature (like highlight execution)" - I disagree. Automatic Error Handling is not really a debugging feature. It is a "safety net" that ensures unhandled errors  are presented to the programmer. Of course, always wiring the error wire (thus defining "manual" or non-automatic error handling) throughout an application is the gold-standard of error handling in LabVIEW. But even when aiming to manually wire all errors, having AEH enabled is useful as it protects in the eventuality that one or more error out terminals become unwired. In other words, an application might be fully "manually wired" this moment, and not so the next (because the programmer edited the code).

In short, the difference between a debugging tool like highlight execution and AEH is that when you are using the debugging tool you already know that you have a problem, and you are actively trying to fix it.

AEH is most useful when you don't yet know that you have a problem. It is there to highlight problems that, if not manually wired, would disappear into a void.

"but generally agree it's useful to make the setting more available" - Fully agree.

"(vs. something more advanced like reentrancy, which should stay in properties)" - I disagree. I think re-entrancy is a very important setting and it too should be made more available. I agree that re-entrancy seems like a more advanced concept, but IMO that's not so much intrinsic to the concept as is due to what I feel has been a lack of  enough discussion of the differences between the three types (non-reentrant, shared reentrant, and preallocated reentrant) in the Core 1 and Core 2 courses (which I'm sure most of us have studied at one point or another), and/or in the community (user groups, etc).

The following is an excellent (perhaps the best) resource on reentrancy: https://www.ni.com/docs/en-US/bundle/labview/page/reentrancy-allowing-simultaneous-calls-to-the-same... . It contains the following extremely useful summary.