LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Nicer .NET Exception Formatting

I am calling .NET functions from a VI, and if an error occurs then the functions throw exceptions, which LabVIEW handles using the error line.

 

I've connected the 'source' field of the error line to a string indicator. It shows something like:

 

Invoke Node System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. Inner Exception: Foo.Bar: Unable to communicate <append><b>Foo.Bar</b> in Test.vi

 

Is there a way I can extract just the actual error message and show only that? In the example above it is "Unable to communcate". I think some end users of my VI will be confused by the .NET generated pre-amble and don't care if .NET is being used. Plus they have to read through the whole thing to find the actual error. So I would like to make this a bit more user-friendly.

 

Thanks!

 

0 Kudos
Message 1 of 3
(2,821 Views)

@aayre wrote:

I am calling .NET functions from a VI, and if an error occurs then the functions throw exceptions, which LabVIEW handles using the error line.

 

I've connected the 'source' field of the error line to a string indicator. It shows something like:

 

Invoke Node System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. Inner Exception: Foo.Bar: Unable to communicate <append><b>Foo.Bar</b> in Test.vi

 

Is there a way I can extract just the actual error message and show only that? In the example above it is "Unable to communcate". I think some end users of my VI will be confused by the .NET generated pre-amble and don't care if .NET is being used. Plus they have to read through the whole thing to find the actual error. So I would like to make this a bit more user-friendly.

 

Thanks!

 


There is no native way built into LabVIEW - but that's not to say you couldn't do the string parsing yourself. You'd have to assume that the formatting wouldn't change between LabVIEW versions (if that is of concern) but I have done this for small projects where the risk is low.

 

Another option I have used is to create a .NET assembly whose sole job is, when given an Exception instance, to unwrap the appropriate parts and return them to the caller. This is probably the most robust way but you have to be able to create said assembly yourself.

0 Kudos
Message 2 of 3
(2,796 Views)

Thanks. I solved this by keeping a reference to the last exception thrown in my assembly, then adding a GetLastError function to the assembly to get just the error message from the last exception. Then if the status property of the error line is true, I call the function and output to a string indicator.

 

0 Kudos
Message 3 of 3
(2,770 Views)