DQMH Consortium Toolkits Feature Requests

Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
j-medland

Add Error Constants Error Codes to the Public API

Status: Declined

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.

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
 

5 Comments
Ozfarmboy
Active Participant

One workaround you might find useful: Antidoc generates a doc with a sub-section within each DQMH module's section, that lists all of the errors 

Christopher Farmer

Certified LabVIEW Architect
DQMH Trusted Advisor
http://wiredinsoftware.com.au

I'm Speaking at the GLA Summit!

j-medland
Member

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.

API.png


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.

Olivier-JOURDAN
Active Participant
Status changed to: Declined

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.

Olivier Jourdan

Wovalab founder | DQMH Consortium board member | Certified LabVIEW Architect |
j-medland
Member

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.

 

Thanks everyone for looking at this!

 

John

Olivier-JOURDAN
Active Participant

Thank you for your feedback and your trust in DQMH Framework.

Olivier Jourdan

Wovalab founder | DQMH Consortium board member | Certified LabVIEW Architect |