LabVIEW
Best Practices for Custom Error Codes in All Projects
Hey all,
So I have a bunch of libraries that get packaged and put into the palettes using VIPM. They are used everywhere in a bunch of my projects, and I'm now starting to run into the problem of generic LabVIEW error codes meaning multiple possible things.
To be more specific, error code -2147467259 can come from either VIs within "DB Library.lvlib" (indicating that the DB connection couldn't be established), or from "SmartMotor.lvlib" (indicating that the SmartMotor connection couldn't be established). I want to be able to handle these two cases differently in all of my projects. What I would ideally like is to capture any error -2147467259 from DB Library and replace it with one custom code and message, saying something like "Network Error: Restart computer and check your wifi before calling me down there.", and similar for SmartMotor.lvlib.
I've read about Defining Custom Error Codes to Distribute throughout Your Application but I'm not sure how to take the information from that and apply it to my situation. As always, any help is greatly appreciated.
I have a feeling there will be as many ways as responses. All I can say is that I haven't standardized on anything yet. Custom errors in LV are super-klunky.
I don't think that you need custom error codes. You need code to handle the error code appropriately. In this case you might want to capture the error code and the source and then take the appropriate action. I reserve custom error codes for errors which are not defined by LabVIEW error codes - a value out of range, for instance.
@johntrich1971 wrote:
I don't think that you need custom error codes. You need code to handle the error code appropriately. In this case you might want to capture the error code and the source and then take the appropriate action.
That's exactly what I'm doing now, but I feel like the more elegant solution would be to, from within the VIs of each library, capture the problem error code and replace it with a custom error code that LabVIEW doesn't use. It just seems more dynamic that way; who knows how many other places this generic error code is going to show up, and how many Boolean indicators this subVI will end up with.
Instead of custom error codes, I always try to find a standard error code that matches, then use "Insert Info In Error.vim" (attached) to add extra info.
I can't open that as it is in 2018 and I'm running 2017 currently, but I feel like it does about the same thing as MGI's "Append String to Error Source.vi". Either way, not a bad idea!
@FireFist-Redhawk wrote:
@johntrich1971 wrote:
I don't think that you need custom error codes. You need code to handle the error code appropriately. In this case you might want to capture the error code and the source and then take the appropriate action.
That's exactly what I'm doing now, but I feel like the more elegant solution would be to, from within the VIs of each library, capture the problem error code and replace it with a custom error code that LabVIEW doesn't use. It just seems more dynamic that way; who knows how many other places this generic error code is going to show up, and how many Boolean indicators this subVI will end up with.
I wouldn't do it this way. I would actually go ahead and handle the error inside the error handler - no need for making a bunch of booleans. You have to handle the error somewhere. One way to handle this would be to make an error class and then make a child class for each of your libraries. You can use an override vi so that the error handler runs the correct error handling for the library that you're using.
@johntrich1971 wrote:I wouldn't do it this way. I would actually go ahead and handle the error inside the error handler - no need for making a bunch of booleans. You have to handle the error somewhere. One way to handle this would be to make an error class and then make a child class for each of your libraries. You can use an override vi so that the error handler runs the correct error handling for the library that you're using.
It's a good thought, but that wouldn't work for me. The main reason is that the handling of a disconnected motor involves enqueueing several states (in the case of it being disconnected in the middle of a test) to the state machine. I have to cancel the test, drop all the data, make a "Reconnect to motor" button visible, etc.
Doing it that way would also lock me into handling the error the same way for every application, and for every place within an application. Sometimes I might want a big red dialog to come up saying a database save didn't happen. But if a database connection couldn't be established when the application starts, just something smaller saying "Check your wifi" would be better. Likewise, there's a big difference in handling an initial motor connection failing vs. the motor's USB being jerked loose in the middle of a test.
I really appreciate the input though!
That’s the magic of doing it in a class. You’re not locked in to doing it the same way. The class knows what to do, and the specific class can be chosen at runtime. You can store all the information that’s needed to properly handle the particular instance of the class in the class private data. Every library can have their own class with their own specific routines as long as they’re a child of the parent class. Your error handler then would get a class and an error wire. The correct child will run based on the class that is passed to the dynamic input terminal.
