How would you redesign the LV error cluster?
I went mucking around inside General Error Handler.vi and am aghast at what I found. It seems like error definition is split between error code lookup (defined in error files) and extra information jammed into the description string using bracketed tags (like call chain and suggestions for handling the error). Why we're forced to handle specific error codes anyway is beyond me. There isn't any way of knowing which codes will be thrown by a given function, and many of the first 100 codes are reus
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 c
