04-23-2009 02:40 PM
I would like to create my own error codes for a CVI dll but I want to make sure I don't use error codes already defined for something else. Is there a range reserved for such use?
Samee thing for warnings (errorcode > 0)
Thanks
04-23-2009 03:48 PM
I use positive numbers for my error codes.
Not only CVI but also almost all other 3rd party libraries use negative numbers for error codes.
So I preferred positive numbers to avoid confusion when generating corresponding error messages.
I define various error check macros for my functions and 3rd party libraries, so that I do not have to write if-claueses after each library function call.
Those macros look like this: ChkErr(fcall) if ((iErrCode = (fcall)) != 0) goto ABORT
I recommend using that aproach, it makes the code clear and well covered for errors.
Hope this helps,
04-23-2009 03:53 PM
04-23-2009 04:23 PM
I have never found a positive mention of a "safe" range of error codes available for user-defined error conditions, but I can suggest you some source of informations.
First of all, every library has its specific list of error codes, usually listed in the relative include file. All these error codes are listed in the online help too (search for "error codes" in the index tab of the help).
Second, GetGeneralErrorString () is a function that can be used to trap errors of the following libraries with a unique error function:
This means that the error codes from this libraries do not overlap, so you could derive from its code some ranges not used by these libraries.
Nevertheless, there is not a single function for error trapping: every library has its proper list of error codes and a function to decode them in human readable form, andthere is no guarantee that these ranges does not overlap. It's up to you to trap errors from every function in the proper way.
04-24-2009 12:56 PM
I run into this all the time, some think that the errors must be unique. Since there are so many, and no single entity that would be in position to control the numbering in all cases, I tell developers to not even try, and as Roberto says provide a function string = xxxxGetErrorString (error code); so that the calling code can at least get a unique human readable message is he chooses to handle the error in the calling context.
It's kindof like handling exception I think. There's a rule of thumb in exception handling that says unless the exception is handled at the lowest level (where first encountered, without re-throwing it) then it's unlikey to get properly handled at all. So if an error code is returned and you chose to not react/log/interpret it where it is uniquely known, then it doesn't much matter, it wasn't that important 😉
In today's era of large capacities (well, on PC's at least) there's usually room for a good sized log file that can hold human-readable strings rather than (potentially overlapping) error codes.
Menchar
04-25-2009 06:08 AM
Of course it is not possible to use the positive numbers blindly.
You need to check the libraries you use, but positive numbers are less likely to overlap with most other libraries' error codes.
I am in the middle of a large DLL project I'm writing in CVI (bunch of functions to be called by a TestStand sequence from this dll).
I prefered to set an error code as the return value of almost every function. I used 0 (zero) for no error and non-zero values (positive or negative depending on whether they are generated by me or another library) for errors.
I used passed-by-reference variables to output any values and I put an error message parameter at the end of my parameter list of these functions to output any error message generated by either my function (if the error code is positive) or the other library function. (For TestStand users: I passed this error message to Step.Result.ReportText whenever possible, if the output values needs comparison I added no-adapter numeric limit steps just after the function call)
If an error code is returned from any function I passed the control with the goto's in the macros (I mentioned in my previous post) to the end of the function where the error message is determined or just to return the error code to the calling function which will eventually determine the error message.
Using this approach I got pretty good error coverage and good error logging. And all functions together look like a consistent library with error codes returned and error messages output as parameters.
Hope this helps,
11-05-2010 08:19 AM - edited 11-05-2010 08:19 AM
I think this is a good suggestion, so I've just filled a product suggestion in CVI Idea Exchange.