Nested Try...Catch

[nbrege]

Is nesting Try...Catches considered bad programming practice?

            Try

                'do something here

            Catch ex As Exception

                Try

                    'do something different here if the first thing fails

                Catch ex2 As Exception
                    MessageBox.Show(ex2.Message, "Error")
                End Try

            End Try

[jmcilhinney]

No, that's fine.

[Shaggy Hiker]

Remember: Try...catch costs nothing if you don't have any exceptions. Nested works the same way, so do what is reasonable to you, so long as what you are catching are things that are exceptional.

[sapator]

It would be advised to try to catch the type of the thrown exception.
For example you want to catch zero division exception you can use DivideByZeroException .
Additively you might know what exception might get at a specific code path so you can test by providing erroneous data or right it down when you catch an exception so you can change it to the appropriate one.
Here is a list
https://mikevallotton.wordpress.com/...s-all-of-them/

Also to be fair it might be a lot of work to specify each an every one exception especially in a long exception code, so I would get at least the obvious one. But it's your choice. I tend to name catch the SQL exceptions as most of my work is done there.

[nbrege]

Here is my particular situation, in case anyone cares. We receive Excel spreadsheets from a customer, that has data for an order. I then connect to these spreadsheets using Oledb to populate a couple columns that are blank that need to be filled in. I was using the code below for several months, which worked fine, until one day it didn't.

oleCommand.CommandText = String.Format("UPDATE [Sheet1$] SET [F9] = '{0}' WHERE [F7] = {1}", FGnum, ppiOrder)
oleCommand.ExecuteNonQuery()
oleCommand.CommandText = String.Format("UPDATE [Sheet1$] SET [F11] = '{0}' WHERE [F7] = {1}", runNum, ppiOrder)
oleCommand.ExecuteNonQuery()

I discovered that I now need to use single quotes around my 2nd parameter. ('{1}'). Something in the format of the spreadsheet must have changed. I wanted to come up with code that can handle either situation, in case it changes again. Here is what I'm doing now, using nested Try...Catches.

Try
    oleCommand.CommandText = String.Format("UPDATE [Sheet1$] SET [F9] = '{0}' WHERE [F7] = '{1}'", FGnum, ppiOrder)
    oleCommand.ExecuteNonQuery()
    oleCommand.CommandText = String.Format("UPDATE [Sheet1$] SET [F11] = '{0}' WHERE [F7] = '{1}'", runNum, ppiOrder)
    oleCommand.ExecuteNonQuery()

Catch ex As Exception

    Try
         oleCommand.CommandText = String.Format("UPDATE [Sheet1$] SET [F9] = '{0}' WHERE [F7] = {1}", FGnum, ppiOrder)
         oleCommand.ExecuteNonQuery()
         oleCommand.CommandText = String.Format("UPDATE [Sheet1$] SET [F11] = '{0}' WHERE [F7] = {1}", runNum,  ppiOrder)
         oleCommand.ExecuteNonQuery()

     Catch ex2 As Exception
          MessageBox.Show(ex2.Message)
     End Try

End Try

It first tries to update the sheet using single quotes. If that errors out then it tries it without the quotes. The error text I'm getting is "Data type mismatch in criteria expression." I don't think there's a specific exception you can catch for this. Is there a better way to handle this situation? If there's one thing I've learned over the years, it's that you can't count on a customer to provide consistant data.

[sapator]

For execnonquery https://learn.microsoft.com/en-us/do...iew=net-8.0-pp

[Shaggy Hiker]

I'd say that the layout is all you can do, as far as the code goes. If you can figure out who changed what with the Excel spreadsheet, that's worth doing for the sake of your sanity, but that's not entirely a coding question (though most of us have probably had to do that, as well).