LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
GoofyWires

Error hierarchy using tags for families/subjects of errors -> ignore errors with a specific tag

Status: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.

Hi,

NI could organize the error numbers into trees of relevance according to tags assigned to each error either by NI or by us.

Thus, we could say that errors x, y and z are related to missing files, for example, and that a, b and z relate to TDMS files.

Once this is done we could use a new ignore error block that will ignore families of errors instead of specific errors.

Many times you don't know which errors could come out of your code but you might be able to handle general common issues even if you don't know the specific error number you'll get for them.

Moreover, each error you customize and create could get it's own tag from the general list or from a new tag you create.

This will organize the errors and help users better understand which errors are already available.

It is sort of an OO Error System.

One error could appear in several red/black trees so the search could be fast and a user could even ignore errors that answer to the cut between several families of error (related to both TDMS and to missing files).

Dror.

3 Comments
crossrulz
Knight of NI

Personally, I'd much rather know exactly what error has happened and then decide from there what is allowed an what is not.  Ignoring a family of errors is just a cheap way out.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
GoofyWires
Member

Same here!

Ideally it is best to handle all errors that may appear.

However, in a large scale project, while using many methodologies and tools, you might not find all the errors while testing the product before you release it.

Moreover, you might know how to treat an error but between LV's version changes or between some tool's version changes the code you handled changed its number.

Having errors with no meaning attached is a bad idea also since one plugin might use the same error number as the other and without good documentation it might be hard to know what is the meaning of it if the code wasn't written by a good programmer using LV official tools.

I see no harm by adding tags to error numbers and it will also help me a lot to use existing error numbers instead of creating my own if there is already a relevant error number I didn't know about.

Darren
Proven Zealot
Status changed to: Declined

Any idea that has received less than 2 kudos within 2 years after posting will be automatically declined.