From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
MarkCG

In documentation of all vi.lib VIs, include list of error codes they can throw

Status: Declined

Declined for reasons listed in AristosQueue's post:

 

"We used to do this, a decade and a half ago. We explicitly removed the documentation. It is impossible to maintain that list accurately if a lower level API adds a new return value. APIs build on each other, and tracking all the dependencies really isn't feasible, especially when error codes are often dynamically generated or come in from DLLs. The partial lists were worse than useless as they were misleading. When Microsoft removed per-function-errors documentation from its APIs, we surrendered to the inevitable -- they had way more resources than we did to track that information and still couldn't keep it up to date. We do still note a couple of specific errors, especially when we think it'll be common to do something specific on a particular error code, but it isn't common."

It would be nice to know what all the possible errors a VI could throw are. This would be pretty useful because you could look at that list and decide which codes you want to implement special handling for, instead of relying on testing or prior knowledge. Would be especially useful for networking VIs ( UDP, TCP, network streams) and file i/o. 

2 Comments
AristosQueue (NI)
NI Employee (retired)

We used to do this, a decade and a half ago. We explicitly removed the documentation. It is impossible to maintain that list accurately if a lower level API adds a new return value. APIs build on each other, and tracking all the dependencies really isn't feasible, especially when error codes are often dynamically generated or come in from DLLs. The partial lists were worse than useless as they were misleading. When Microsoft removed per-function-errors documentation from its APIs, we surrendered to the inevitable -- they had way more resources than we did to track that information and still couldn't keep it up to date. We do still note a couple of specific errors, especially when we think it'll be common to do something specific on a particular error code, but it isn't common.

Darren
Proven Zealot
Status changed to: Declined

Declined for reasons listed in AristosQueue's post:

 

"We used to do this, a decade and a half ago. We explicitly removed the documentation. It is impossible to maintain that list accurately if a lower level API adds a new return value. APIs build on each other, and tracking all the dependencies really isn't feasible, especially when error codes are often dynamically generated or come in from DLLs. The partial lists were worse than useless as they were misleading. When Microsoft removed per-function-errors documentation from its APIs, we surrendered to the inevitable -- they had way more resources than we did to track that information and still couldn't keep it up to date. We do still note a couple of specific errors, especially when we think it'll be common to do something specific on a particular error code, but it isn't common."