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!
Cheers
John
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.