How to pass .NET/COM errors to the error out - terminal of a property/invoke node?

[chrisger]

hi there

ok, this is not really a LabVIEW question:

i'm about to create a .NET assembly which will be accessed by property and invoke nodes. i'd like to know if there's a way to pass custom error codes from inside the .NET assembly to the LV environment via the error out - terminal of the calling property (just like the Microsoft .NET assemblies and COM objects, e.g. TreeView, ListView etc.)

Anyone ever done something like this?

Thanks in advance

[tst]

As far as I know, LV always passes error 1172 when there is an exception and you can return details in the source element, which can then be parsed. This might have been changed with more recent versions, but as far as I know it wasn't. I suggest you search Brian Tyler's blog, as I think he explained it there once. Here's a recent explanation.

[PJS]

I read a posting the other day (they muddle together eventually) about the information that labview captures when there is an error in the .net assembly. It will through up a 1172 error, I do not believe you can avoid the error number.  I searched but can not find the post.  Ahh TST found it.  JonathanN seems to be the .net expert here and maybe he can provide more detail.
Here are just a couple work arounds I could come up with.

1. Put out a callback event with the error information.
2. Provide a 'get error method'.
3. Build a VI that parses the text output from the error, and converts that to your custom error code.
   

I don't think it is what you are looking for, but they are the only options I can think of at the moment. I hope that helps, or maybe Jonathan can shed more light on this.

Message Edited by Stradis on 09-12-2007 08:43 AM

[chrisger]

thanks both of you

this generic .NET error 1172 is passed to LV only at problems inside the .NET framework like a missing .dll or something like that, is this correct?

but how can i pass my own errors from inside my C# code to the error out terminal? i haven't found a way for doing that.

because i'm stuck at LV 7.1 i can't use a callback event.

at this point for me the best way is a 'get error method' like stradis suggested.

[tst]

As far as I know, any exception should throw error 1172. That includes exceptions you throw. At least that has been my experience.

I believe missing DLLs will either break your code or throw error 1172 (it's been a while since I've done this last), but if I remember correctly, having missing dependencies in the .NET code does not necessarily propogate the exception to you. However, as I said, it's been some time since the last time I tested this and I only did the LabVIEW side of the code.

[chrisger]

now i know how to create my own error messages:

public MyExceptio()
{
  try
  {
     int a = 0;
     int b = 0;
     int c = 0;

    // create exception
    c = 1 / a;
   }
   catch(Exception e)
   {
     System.Exception myExc;
     myExc = new System.Exception("1234:This is my own Exception error message which i can parse");

    // look here!
    throw(myExc);
   }
}

maybe i'll choose the error parsing method

[JonathanN]

Hi chrisger,

I just saw this post and I thought I might say a couple of words.  

In LabVIEW 7.1, there really wasn't any information given to user about the exception that occurred.  You would get the standard 1172 error which basically means "A .NET Exception Occurred" which really isn't that helpful. In LabVIEW 8, we added more information to the error string but that isn't easy to parse for programmatic control.  

Since LabVIEW currently doesn't have a way to retrieve the exception object, here are some suggestions you might want to consider.  One suggestion is to put try/catch blocks around your assembly methods and return the exception object from the method call or return null if no exception occurred. This gives you a reference to the exception object and thus you can do all sorts of programmatic handling. Now that you have this .NET exception object, you have full access to properties like InnerException, Message, Source, StackTrace, etc and access to the methods and type information. So you say something like (the code below is done in C#):

public class classJonathan
{
    public Exception forceException()
    {
        int a, b, c;
        a = b = c = 0;

        try
        {
            c = 1 / a;
        }

       catch (Exception e)
       {
           string exceptionMessage = "Error 12345: This is my exception error message"; 
           Exception myException = new Exception("Default exception message is "
           + e.Message + "\nMy error message is - " + exceptionMessage);

           // You could also throw the exception as well
           // throw (myException);
          
           return myException;
        }
        return null;
    }
}

If you threw the exception, you would get something like the attached snapshot LabVIEW Error Message.jpg (this is in LabVIEW 8.5). Another suggestion is if you are positive that the assembly or object instance will only be access from a single thread, you could have some sort of Last Error property on the object that you could query if you get an error in the error cluster. 

Just one side note, any exception thrown in a call to a property or method of a .NET object is converted into a LabVIEW error with the standard error code 1172. 

Just some thoughts

Best Regards,

[chrisger]

Hello Jonathan

Thanks for your answer.

After i had a conversation with my customer we agreed to use an int32 return value for methods where approbiate. in all other cases we use a GetLastError method providing us an int32 error code (the assembly is attached to some custom hardware and therefore always in a single thread). As we use exception handling in any cases we sould be able to react on the 1172  - errorcluster from the error out terminal of the LV nodes, but we retrieve the information about the error code from the return value/GetLastError method (instead of parsing the source string).

This is more convenient when calling the assembly from other text based languages. for LV it dosn't matter if i call the GetLastError Method or create a VI to parse the error source string. Another advantage is that i now can define my error codes inside the C# code as simple const int instead of creating some lengthy strings just to parse them afterwards.