Honour each VI's Automatic Error Handling setting in EXE

[Petru_Tarabuta]

Automatic Error Handling (AEH) is a useful feature. It captures errors that were otherwise left unwired by the programmer (intentionally or accidentally). It represents a "safety net" that can make the programmer aware of errors that they may otherwise remain unaware of.

Problem: Currently AEH functionality is only available in the development environment. It is not available in built executables. Even when all VIs in a project have AEH enabled, once built into an EXE, all VIs behave as if AEH was disabled.

Solution: It should be possible to honour each VI's AEH setting in built EXEs too, not just in DevEnv. The EXE build specification could contain a setting named "Honour each VI's Automatic Error Handling setting in EXE". When ticked (enabled), any VIs for which AEH was enabled in the development environment will continue to benefit from AEH behaviour in the EXE. Any VIs for which AEH was disabled will continue to have it disabled in the EXE. This means that, from an error handling/error manipulation point of view, the application would behave identically when being run as an EXE as when being run in Development Environment. This is more consistent, and can be helpful.

The current behaviour (forcibly removing AEH in EXE) means that EXEs are prone to having errors that were not discovered during DevEnv testing being "swept under the carpet". In other words, currently EXEs are overly "optimistic" - they can make the programmer believe that everything is ok when in fact one or multiple unhandled errors are occurring, errors that would have been visible in DevEnv. This is particularly relevant to apps that run for long periods of time (e.g. life cycle testers) that may encounter errors that were simply unforeseen or untested in DevEnv (e.g. error after one month of continuous running due to running out of disk space when saving measurements log file to disk).

The screenshot below shows how the new setting could look like in the Advanced page of the EXE build spec.

Notes

• To be absolutely clear: I am not asking for AEH to be enabled by default in all EXEs. I am also not asking for AEH to become enabled in all VIs when the new build spec setting is ticked.  This would override the AEH setting of all VIs - I am not asking for this.
• The default value of the new setting should be False (unticked). When False, the built EXE would behave exactly as it does now - AEH would be disabled in all VIs. This would maintain the current behaviour as default.
• The new setting would give the programmer more control - it would allow the programmer to decide whether they want AEH or not in their EXE. Currently AEH is taken away in EXE, even when we (professional LabVIEW programmers) might want it enabled.
• I would be happy if the new setting was available only for desktop, non-real-time applications, and not on Real-Time targets.

[OneOfTheDans]

Better solution is eliminating AEH from the IDE altogether. The feature gives new developers enough rope to hang themselves as they build small-to-medium sized projects, then try in vain to retrofit useful error handling.

Adding this feature to EXEs just perpetuates bad LabVIEW code.

[raphschru]

If you are afraid of forgetting to wire the error output of your nodes, why not setup VI Analyzer to check that?

[Petru_Tarabuta]

"Better solution is eliminating AEH from the IDE altogether." - I couldn't disagree more. AEH is an extremely useful feature.

Below is a slightly edited copy of a comment I recently posted to this idea. I'm copying it below for the benefit of people that may not be following both threads.

"

AEH 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.

" (end of comment copied from other thread)

"The feature gives new developers enough rope to hang themselves as they build small-to-medium sized projects" - AEH can certainly be misused. To be clear, I do not recommend relying solely on AEH as a means of error handling. The gold-standard of error handling in LabVIEW is, of course, manually wiring all error out terminals. AEH is useful as a safety net in addition to manually wiring all (or virtually all) error out terminals.

"Adding this feature to EXEs just perpetuates bad LabVIEW code." - Exactly the opposite. Adding this feature to EXEs means that the EXE end-users will become aware that the application is experiencing errors and will request from the programmer that these errors are fixed. Contrast it with the current situation where an EXE can easily appear "error free" when in fact there could be multiple errors occurring during a test run. Turning AEH off is the perfect "just sweep it under the carpet" technique.

"If you are afraid of forgetting to wire the error output of your nodes, why not setup VI Analyzer to check that?" -
1. VIA is a paid-for add-on that is part of LabVIEW Professional edition, but not of the Base and Full editions, as can be seen in the "Dynamic and static code analysis" line item here. Therefore not all programmers have access to VIA.

2. Only a subset of people who have access to VIA actually use it.

Nevertheless, I agree that it is a best practice to regularly run VIA tests to check that all error outputs are wired. Being able to have AEH enabled inside EXE is complementary to that best practice, not opposed to it.