Error Descriptions

[JamesMc86]

Review the MGErr list at https://www.ni.com/docs/en-US/bundle/labview/page/labview-manager-function-errors.html and bring descriptions into the error module.

[jkneer]

I have a branch in my fork that has the full list of ErrorCodes (MgErrorCode) and an thiserror (MgError) implementation.For now I implement From back and forth, but we probably also want a i32 conversion? Also right now I do not fully grasp the design intent of the current Errors, before putting in more work I would like to discuss the details.

[jkneer]

This LV function converts a numeric error code to the associated text description: https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/properties-and-methods/lv-manager/nigetoneerrorcode.html

Here is a list of all general labview error codes: https://www.ni.com/docs/en-US/bundle/labview-api-ref/page/errors/general-labview-error-codes.html

[JamesMc86]

This issue was intended including MGErr values in the crate error type. That error converter looks really useful though and I'll open a separate issue to track adding that.

[jkneer]

I just found these additional lists:

https://labviewwiki.org/wiki/List_of_errors https://labviewwiki.org/wiki/LabVIEW_Error_Code_Family

[jkneer]

After looking at those long lists of error codes, I realised how futile it is to try and store them...

Lets think about the use cases first (sorry for the formatting and poor grammar, just throwing out some thoughts):

LV to Rust: Getting an error from LV into Rust is probably only a minor use case. As usually code in labview would rely on something to execute correctly in Rust and not the other way around. There may be additional use cases like logging inside the Rust dll, where it could be beneficial to have an interpretation of an error handed in. But then also an error handed in will have the form a an error cluster with an attached description.

Rust to LV: The main channel to transport an error to LV is the return code of the dll function. Using this channel, one has to use standard LabVIEW error codes, so the user can make sense of them in LV. A potential second transport channel is to include a error cluster parameter in each dll call:

output: Error from DLL to LV:

• We should supply a small number of standard errors with good short hand names to support concise error naming while programming. Instead of including all obscure errors, it seems much more helpful for the programmers to only support a few well selected ones that cover most general cases. This LabViewError needs to impl From<MgErr> (and vice versa)
• It should be possible to append a custom error status to any of the predefined LabView Errors.
• InteropError is probably an enum of LabViewError, our own internal Errors and external Errors. How do we translate the non LabViewErrors to LabView Errors that we transport back to labview. How can MgErr impl From<InteropError>?
• How do we translate Rust Results of any other type into MgErr? How do we translate Rust Results of any other Type to LabviewError and how to an ErrorCluster?

input Error into the DLL: What if it is a warning, what if it is an error, how to translate that ? This is probably best dealt with, with helper functions that an author of a DLL can use, to support whatever behaviour they want to implement.

29 -> get error descriptions

33 -> update error Clustesr

[JamesMc86]

TLDR: What you had already in a branch should fulfil this in a branch.

As you say there are multiple error paths, in fact I think there are 3:

• LabVIEW Memory Manager --> Rust - this is the MgErr which has all of the possible options at https://www.ni.com/docs/en-US/bundle/labview/page/labview-manager-function-errors.html
• Rust --> LabVIEW - This could be a custom routine that someone creates or we have some ability to format it into a LabVIEW error cluster in https://github.com/WiresmithTech/Rust-LabVIEW-Interop/blob/main/labview-interop/src/types/lv_errors.rs
• LabVIEW --> Rust - This can also use the Error Cluster but we may want to be able to support that long list of errors. But instead of embedding those we should do #29 and use the LabVIEW manager to convert them.

So for this issue, lets just focus on the LabVIEW memory manager to Rust - that will complete the work on the MgErr type and then we can worry about working with error clusters!