Problem: Currently it is impossible to know in advance what errors (what error codes) a node or native VI can produce. (Native VI = VI that ships with LabVIEW)
For example, I recently implemented a module that communicates with another endpoint using the LabVIEW TCP primitives we know and love: TCP Open Connection, TCP Read, TCP Write, TCP Close Connection. In order to create robust software I needed to understand what error codes each of these primitives can generate, and in what circumstances.
Through initial testing I discovered that TCP Open Connection can generate errors 56, 62, and 66. I then handled these errors locally in the code.
Around two weeks later, during further testing of what I thought was a fully complete and tested module, the module unexpectedly started experiencing error 60 many times per second. The module had never experienced error 60 before. The module was configured to broadcast an event each time an error was detected. This flooded the listener (the DQMH tester VI that was listening to all broadcast events) with thousands of error messages per second. The tester VI front panel buttons became unresponsive, because the tester was flooded with so many incoming broadcasts. The only way to break out of the cycle was to abort the tester, then close the project to shutdown the module.
This way I learned "the hard way" that that TCP Open Connection can generate error 60 in certain circumstances, in addition to the error codes I had handled already.
Solution: The detailed help of each node and each native VI should list all error codes that can be produced by that node or VI. For example, in the case of TCP Open Connection, the detailed help should contain a description similar to the below.
"
TCP Open Connection can generate the following errors:
- Error 56
- Error 60
- Error 62
- Error 66
- and so on listing here any/all error codes that can be generated by the node.
"
This list would be extremely useful, as it would make us (professional LabVIEW programmers) aware of the various error codes a node or VI could occur generate. This would encourage the programmer to think of ways to handle all those possible errors, thus resulting in more robust code.
By reading the "Explain Error..." message of each error code the programmer could also understand the circumstances in which the node or VI generates each particular error.
Notes
- In summary, this idea suggests an improvement to the detailed help documentation of each node and native VI.
- It should be possible to automate the creation of the lists for each node and native VI.
- For nodes whose source code is written in C++, a program could be created to scan the source code files and return the list of possible error codes generated by the function.
- For native VIs, VI scripting could be used to achieve a similar purpose and output the list of errors that could be generated by that VI.
Thoughts? 
Here we have a combo box vs enum in an array. Both contain identical lists which consist of the following: 
Right click the enum and you don't: 
