From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Anyway, your request points out a lack of documentation for the reserved range of errors we use internally. we are considering updating the documentation accordingly.
Concerning the errors specific to a module, we encourage you to use Antidoc to get the list of the existing error or look at the code.
The DQMH library has several errors defined in privately scoped VIs like "Module Not Running--error.vi".
It feels like the error codes associated with these error constants form part of the public API but there is no way that the library caller can know what these codes are without the omnipotent powers of the developer looking into the code (or deliberately triggering the error in an API call).
What would be people's thoughts on providing some public VIs which wrap up the private error constant VIs and just output the code for use with the things like the "Clear Errors.vi" or other error handling logic?
I know these could be added to a custom template but if the point of the DQMH is to encourage good practice then avoiding magic numbers in the caller's error handling logic is a win right!
Thanks, Chris - This sounds like a nice idea and another excellent reason to use Antidoc.
I guess my explanation was a bit lacking and I appreciate that some of this is down to my views on API structuring and code/convention/documentation.
I thought I would add a picture to better explain what I am thinking and one of the use cases it would facilitate.
Now if there are any changes to the error codes used by the DQMH module the calling code will automatically track them.
As a developer, it is easy to add this into an existing DQMH module/create a custom template/additional scripting but being selfish, it would be nice if it happened automagically and so everyone shall suffer the wrath of my opinions.
Anyway, your request points out a lack of documentation for the reserved range of errors we use internally. we are considering updating the documentation accordingly.
Concerning the errors specific to a module, we encourage you to use Antidoc to get the list of the existing error or look at the code.
I think after consideration as to how error codes are generally handled with case structures, having a clear list in the DQMH docs is probably the best option.
I would still consider the error codes used to be part of the API so any code changes would only happen at DQMH major version releases.
This is not a priority.
Anyway, your request points out a lack of documentation for the reserved range of errors we use internally. we are considering updating the documentation accordingly.
Concerning the errors specific to a module, we encourage you to use Antidoc to get the list of the existing error or look at the code.