When to consider an event or condition an error?

[gstanczak]

Hello,

Are there any rules of thumb or general guidelines to determine if a somewhat special condition or event should be handled inside of a subvi as opposed to generating an error to be handled by an outside error handling state.  I can't seem to find how to be consistent in this regard.  Is there some level of significance or severity that determines if a particular condition or situation is erroneous and unexpected versus something that is expected to happen, although not that often.  I don't know when to consider an error, an error, basically.

For example, to make sure that the .ini structure that I read and write has not changed since the last time the program ran, I include a section with file structure information (type string from the flatten to string function).  If it has changed, I delete all the contents and write it with all default values in the new structure.  Is that something that would better be performed in my read config file vi, or better handled as an error in an error handling state.  I am looking for some general guidance to determine when to do one or the other.

I hope I am being clear.  I haven't been able to find any posts or literature that address this issue for me.

Thanks as always,

Greg

[Eric_L]

Hello,

Error handling is a complex topic but one general guideline for error handling in Labview is to use error in and error out clusters so any error generated in the sub VI can be identified. In special cases where you may expect a specific error or problem, you can handle that error within the sub VI but should pass an error out to indicate that the error or warning has occurred.

In regards to your example, it is unclear to me what you are trying to do. You read an ini file, but change the parameters back to default if they have changed? If you could explain the application, it would help in understanding this example.

Eric

[gstanczak]

Thanks Eric.  I don't mean that I change the parameters to default if their values changed, I change all to default values when the structure of the file changes, as would happen if I added a new control on the front panel that I wanted to include in the .ini file.  My .ini is not readable, its just a string flattened from cluster with all of the configuration parameters that I want to be maintained, so there needs to be a check that string came from the same type of cluster or things don't work.

-Greg

[Eric_L]

Hi Greg,

If the error can be handled in the sub VI in such a way that your application can still run correctly, I would handle the problem in the sub VI and pass a warning out the error line. Otherwise I would pass the error out into the error handling state. The choice is up to you, I have not found any guidelines regarding this type of specific error.

Eric

[SteveChandler]

Since you are thinking about these things you might want to check out this very intriguing thread on Lava about error handling.

Error handling is such a vast topic. I think the only way to know if something is a "condition" or an "error" is by looking at the specific question/application. But I would say that it is a condition if you anticipate it happening and can correct it or if it is something you know you can safely ignore. It is an error if you can not correct it (or didn't expect it) and the downstream code depends on this vi's success.

I don't consider your example to be an error. The unflatten from string does return an error because it doesn't know how to deal with the input. But you know in advance that this specific error condition could happen (because you want to be able to modify the cluster) and you have the code to deal with it. Once it is dealt with and corrected then the error is gone.

A really good example is the file selection vi. It returns an error if the user presses cancel because operating on an unknown or invalid file will most definately result in an error. But you expect that the user might press cancel so you clear the error and skip the file operations.

Another way to say it is that if you can consider the error to be a message to do something else then it is no longer an error.

I think this is why most programming languages refer to these as exceptions rather than errors. An exception will only result in an error if it can not be handled and is not intentionally tossed out.