How do you organize your custom error code files?

[A Scottish moose]

Hello everyone,

I am working on putting together a test executive that pulls from a lot of external code libraries.  I'm at the point now that I have a fair number of custom error codes generated by different DAQ libraries and keeping track of all of them is becoming increasingly difficult.  I've been using error rings for custom error generation and while not ideal has served well enough until now.  Keeping track of the codes hasn't been hard because they are few and far between.  

I've been thinking about transitioning to a custom error file instead of using ring constants because keeping track of it all is not realistic anymore.  

My question arises from the fact there are ~10 different libraries in this current project all pulling from 3-4 different source control locations and creating a single error file that covers all the errors from these libraries seems incorrect.  I would think custom error records would travel with the library that uses them, but does this create file reference headaches when you start pulling in libraries and external references, PPLs, etc?  

Question: How do you keep track of your custom error codes?

 

Some options that I could see being viable:

A single company wide error code file that gets pulled down with your version control. A blanket approach would make sense and also would prevent error code conflicts from one library to another by forcing communication during modification and addition.

 Error code files packaged with each individual library and pull them all into projects when they are getting developed.  This seems the most modular and portable but could result in conflicts with error code numbers if developers don't communicate about the ranges they are using; also how does LabVIEW do with referencing lots of different error files. 

Cheers,

 

Tim

[hooovahh]

I too am interested in hearing how people tackle this issue.  Personally I think it starts with keeping the number of custom error codes to a minimum.  I have a tool (that I can't seem to find online but thought I posted) which allows to search for errors that might match what you need.  Then I use this as the error code and put in the custom text in an Error Ring with the optional inputs with %s.  Of course one step can be eliminated if you could search in the error ring.  I understand the benefit of custom errors, but the dependency issues, and code ranges usually means I just stick with the ones on the system.

[Darren]

I recently dealt with this issue when designing the LabVIEW Cloud Toolkit for AWS. I had to create a lot of new error codes, that mostly correspond 1-to-1 with the errors that AWS can return. My ultimate solution was that I had an Excel spreadsheet per class (Core, S3, SNS, SQS, IoT), and a build tool that parsed these Excel files and created a separate error text file for each class.

[jacobson]

Our systems engineering group has a table where they keep track of projects/toolkits, error code range assigned, and the project owner. When you need custom error codes for your project you will get "assigned" the next chunk of 50 error code values on the list. These error codes are now yours to do with as you please.

I don't have to manage this list so I can't speak to the drawbacks there but from the perspective of someone who needs to use the system it's pretty nice. I sent a message to someone asking what error codes I should be using and they sent me a link to the internal list, added my name, and told me what error codes to use.

[smithd]

2 hours ago, jacobson said:

Our systems engineering group has a table where they keep track of projects/toolkits, error code range assigned, and the project owner. When you need custom error codes for your project you will get "assigned" the next chunk of 50 error code values on the list. These error codes are now yours to do with as you please.

I don't have to manage this list so I can't speak to the drawbacks there but from the perspective of someone who needs to use the system it's pretty nice. I sent a message to someone asking what error codes I should be using and they sent me a link to the internal list, added my name, and told me what error codes to use.

There was a fairly long period where it wasn't managed, people just went onto the internal page and edited it. Or at least thats what I did.

To answer the question of where to keep them, we kept them with each project (included in the package build) and a completely separate range for each project as mentioned. 50 is an arbitrary range but seemed to work well for full projects and I selected 25 for smaller ones (like plugins). The closest I ever got to 50 was probably modbus, and that was only because (just as darren did above) I translated modbus errors which bloated the range a bit. Once set, it was rare to change the generated code.

8 hours ago, hooovahh said:

Personally I think it starts with keeping the number of custom error codes to a minimum....  I understand the benefit of custom errors, but the dependency issues, and code ranges usually means I just stick with the ones on the system.

This is what I've been doing more recently. 80% of errors fall into 10 codes with maybe some extra metadata. So I made myself a little VI (basically this or this) that does the <append> tag and merges errors if needed, and lets you either use call chain or hard-code a source, and then I twirl through the explain error dialog until I find an appropriate error. This seems to be in line with what those linux guys do. EAGAIN means try again, ENOBUFS means "I'm sorry dave".

Maybe I'm an outlier, but I don't see a ton of added value to the error code past the boolean. As above, linux uses some codes like EAGAIN to signal conditions which are arguably not errors, but labview's easy multiple return values means I'm 0% likely to encode "try again" as an error. So while I check for errors a lot (and cut off error wires at the source where possible), I really don't care about what error it is except to log it, and...lets be honest, error 56 works absolutely just as well to indicate a timeout as -1073807339 does. And while people may hate me, error code 1 seems like a perfectly sufficient way to indicate an argument error provided you append something human readable like "please enter a name into the field, dummy, empty string doesn't work".

Edited June 21, 2017 by smithd

[pawhan11]

Last week I tried to create EH model for my personal purpose. Attached what I ve made so far:

download

I use source which says what created this error eg Labview, DIO or something else, description containing error code, meaningful description and explanation, timestamp and call chain. 

Each driver or module has dedicated source name and I dont have to care about error code uniquness. Error codes can be later stored within application or read from disk.

[hooovahh]

Interfacing with external tools is another interesting one, where the habit is to just do the 1-to-1.  Lets say I'm interfacing with some 3rd party DLL, and on the return they will have a number from 1 to 200 with a table in their documentation stating what the error corresponds to.  I've see times where people will just add a number to every value returned.  I know the ADCS toolkit does something similar to this.  The error code is actually returned as part of the communication.  Here is documentation with a negative response table.  NI just takes a constant of -8000 and subtracts whatever the response value is and uses that as the LabVIEW error code.  This is quite handy because when you get an error code from LabVIEW it will state things like "Service Not Supported" which tells me about type of issue I'm having.  These are the times of error codes that I can't really find an equivalent existing error code for.

[smithd]

2 hours ago, hooovahh said:

NI just takes a constant of -8000 and subtracts whatever the response value is and uses that as the LabVIEW error code.  This is quite handy because when you get an error code from LabVIEW it will state things like "Service Not Supported" which tells me about type of issue I'm having.  These are the times of error codes that I can't really find an equivalent existing error code for.

I agree, except thinking about it made me realize thats a pretty common need if you're interfacing with another device. Instead of "bad parameter" its "you connected to the device successfully, but it says that you gave it a bad parameter" or "you connected to the device successfully but it had an internal error processing your request", etc. There will always be some protocol or application specific errors to be sure, but having a generic family of "this standard error happened, but it didn't happen here it happened on the remote system" makes sense to me. And of course I realized thats almost exactly what http implements: http://www.restapitutorial.com/httpstatuscodes.html . 400 series is "you broke" and 500 series is "I broke" but they are all common enough errors. Except for 418 I'm a teapot.

[infinitenothing]

 

15 hours ago, jacobson said:

Our systems engineering group has a table where they keep track of projects/toolkits, error code range assigned, and the project owner. When you need custom error codes for your project you will get "assigned" the next chunk of 50 error code values on the list. These error codes are now yours to do with as you please.

I don't have to manage this list so I can't speak to the drawbacks there but from the perspective of someone who needs to use the system it's pretty nice. I sent a message to someone asking what error codes I should be using and they sent me a link to the internal list, added my name, and told me what error codes to use.

 

Can I submit range requests? Your group can do what IANA does for IP ports.

 

Also, I use the "Custom Error Code" feature of the error ring which uses the <ERR> tag which removes the need to distribute the XML error file with the executable and allows for descriptions that can help you debug "There's no case for an input of %d"

Edited June 21, 2017 by infinitenothing

[A Scottish moose]

I can see there being some value in the centralized option and this might be what I end up going with.  The point about putting in some time to search for existing error codes is also good.  I can see how there's probably a lot of errors that fall into just a few different categories: task a broken, file is broken, code is broken.

Thank you for the comments so far.

Tim

 

Edited June 21, 2017 by A Scottish moose

[pawhan11]

Might be off topic question, but do You also translate all errors and logs when localisation is required? If Yes how do You do it?

[Tim_S]

On 6/24/2017 at 11:31 AM, pawhan11 said:

Might be off topic question, but do You also translate all errors and logs when localisation is required? If Yes how do You do it?

I have an error log file that keeps track of what errors have occurred and a set of multi-language files that are used for localization. The application that displays the errors uses the information in both for display.