LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

.NET Exceptions handling

Solved!
Go to solution

Hello,

 

I have some basic question about how to handle exceptions comming out of methods I call in LV.

For example :

 

public static void ShowSqlException(string connectionString)
{
    string queryString = "EXECUTE NonExistantStoredProcedure";
    StringBuilder errorMessages = new StringBuilder();

    using (SqlConnection connection = new SqlConnection(connectionString))
    {
        SqlCommand command = new SqlCommand(queryString, connection);
        try
        {
            command.Connection.Open();
            command.ExecuteNonQuery();
        }
        catch (SqlException ex)
        {
            for (int i = 0; i < ex.Errors.Count; i++)
            {
                errorMessages.Append("Index #" + i + "\n" +
                    "Message: " + ex.Errors[i].Message + "\n" +
                    "LineNumber: " + ex.Errors[i].LineNumber + "\n" +
                    "Source: " + ex.Errors[i].Source + "\n" +
                    "Procedure: " + ex.Errors[i].Procedure + "\n");
            }
            Console.WriteLine(errorMessages.ToString());
        }
    }
}

I want to go into sqlexception collection and read all avaliable exceptions.

This class is sealed and has no fields like getlastexception, there is no events raised on error etc.

Can I somehow do this? Or I only have to relay on error cluster comming out of the node. If so how LV handles this internaly when specific node executes ? 

0 Kudos
Message 1 of 4
(3,655 Views)
Solution
Accepted by pawhan11

LabVIEW always wraps exceptions into an error cluster with code 1172. The message ("source") content includes the Exception.Message property (from LV 8 onwards). Often this is enough information to determine the issue if the Message property is sufficiently verbose; in some cases not. However .NET nodes in LabVIEW never return the exception object itself. In your case you need access to the exception object so that you can drill down into the contained SqlErrorCollection object and enumerate through the items.

 

My suggestion would be to create your own C# Exception class that derives from System.Exception. This new class would accept an instance of the SqlException class in the constructor (or otherwise using a property etc. - your call) and then un-wraps the contents of the SqlErrorCollection to a string, basically what you have shown. It then exposes that string on its Message property so that the error cluster out of .NET method call nodes contains this text in the source element. The code you write in your C# assembly always throws this type of exception instead of SqlException ("throw new NewSqlException(ex)"). You will lose the original stack trace information by doing this; however if you want you could append the stack trace information (as a string) to the rest of the un-wrapped string.

0 Kudos
Message 2 of 4
(3,617 Views)

Thanks for reply, very nice written. 

 

Unfortunately creating another c#DLL is not an option in my scenario. It turned out that nodes seem to get valid descriptions about what was wrong. Call chain is not always ok but I can live with that.

 

Do You know how they plan to approach this in LV NXG?

0 Kudos
Message 3 of 4
(3,601 Views)

I believe nothing has been detailed or confirmed regarding .NET integration into NXG; I haven't seen it on a road-map. However I would assume it would be backwards compatible in some manner to allow upgrading from LabVIEW "classic"; probably with more usability features rather than a significant functionality change.

0 Kudos
Message 4 of 4
(3,597 Views)