LabVIEW
How to show all possible errors generated by a given VI
Unless you talk about very trivial libraries, there is never an exhaustive documentation of possible error codes in any programming system I know of. The variables are simply to big, the effort to maintain such information absolutely unjustified, as code is modified, new platforms added that can suddenly cause all kinds of new and different errors, and those platform APIs never document the errors in an exhaustive manner either, if they even document any specific error codes. Often it is more of the type returns 0 on success and an error code otherwise.
Even if such a documentation would exist, it would serve no good purpose, as I'm sure nobody would want to wade through pages and pages of error codes for every function called, and implement an unwieldy case structure to react on those error codes. It also is a sure way to make your code break at the slightest change of anything in your system, even a simple security bug fix to your OS added by automatic upgrade that suddenly introduces new error codes or even changes them for whatever reason.
Robust programming does not react on error codes, but on error situations at specific locations in your code. There is little help in knowing that you have a file permission error somewhere in a 2 hour procedure. It is much more helpfule to know that trying to open the data file to store the measurement results has failed, or that some measurement parameters couldn't be accessed. The error code can then give extra information as to the possible cause, but isn't the most interesting information in the first place.
Reacting on specific error codes only makes sense in very specific situations such as timeout errors that often simply can be ignored and then attempting to retry the operation, or if you want to detect specifically if you are able to access a certain file location with certain access rights and similar things. Here the error code is used to detect that something specific has happened that is an error in the context of the function, but absolutely legitime and expected behaviour under the conditions you are wanting to use that function.
@Provisio wrote:
And lest you believe rolfk, who said "there is never an exhaustive documentation of possible error codes in any programming system I know of", let me refer you to (for instance) UNIX man pages, which list errno's that can be returned by system calls. Here's that portion of the Linux close(2) man page. This is what we want for LabVIEW. What makes NI think this is so difficult? Maybe because for years NI's R&D group has been, well, lazy?
ERRORS
EBADF fd isn't a valid open file descriptor. EINTR The close() call was interrupted by a signal; see signal(7). EIO An I/O error occurred. ENOSPC, EDQUOT On NFS, these errors are not normally reported against the first write which exceeds the available storage space, but instead against a subsequent write(2), fsync(2), or close(). See NOTES for a discussion of why close() should not be retried after an error.
How confident are you that is the complete list? (Let's leave aside that you probably have to include some other header to get something to compare those codes to)
Presumably the man page is just written text. It could be out of date, etc.
If you really want to be paranoid, you'd have to read the code that compiles the call. And then anything that calls. And then... and then... you get the picture.
With LabVIEW, there are a few common error codes for most functions (by which I mean, a given function has a few common errors typically). It'd be nice to have a list, and in some cases there are suggestions of lists (e.g. Network Streams Error Codes) but I wouldn't inherently rely on that being exhaustive.
It may be those are all the errors thrown by design by those functions, but if I want to handle my code's execution carefully, I need to have some error handling that handles the default case.
Beyond that, some depend on various other details (things involving the memory manager come to mind). Some things can cause errors that cannot be passed to an error wire (because the node has no error out), e.g. I believe if you run out of memory, arithmetic nodes might be able to pop up the dialog indicating oom. Build Array is a more typical culprit, but you can't handle that error - only avoid it. You could, if you wanted, look at available memory (perhaps using OS-specific functions) and guess when you were about to have a problem.
I'd suggest that rather than being "lazy", the absence of a list is intended to prevent false reliance on an incomplete (or potentially inaccurate - although you could claim that fails under lazy) list of possible failures (especially in critical applications).
A nice rant! Because that is what this post is!
If I understand you correctly you add after each function call in C a case statement where you carefully list all the documented error codes and then post an according message for each code to stderr? Sounds like the way to go.
Aside that I don’t trust the manpages to be exhaustive but at most indicative (your error handling code of course never has a default case right?) and clib from Linux is in many aspects different enough to other Unix implementations such as BSD and that is different to others, etc.this kind of error handling is not only totally unportable but would also get quickly totally unmaintainable. Are you planning to revisit your entire code base every time you link it with a new version of clib?
Generally speaking functions can return all kind of errors. Some specific errors can sometimes mean something specific depending on the context you call it and you do want to handle that error in a specific way such as retrying the operation or ignoring it in some cases (communication timeouts for instance). Everything else is typically an error that should not have happened and the only useful recourse is to log the error and inform the user and/or restart the operation completely.
