I've caught an exception!! Now what?

Question

I've started using try-catch blocks (a bit late, I know!), but now I'm not sure what to do with the exception once I've caught it. What should I do?

Try
    connection.Open()
    Dim sqlCmd As New SqlCommand("do some SQL", connection)
    Dim sqlDa As New SqlDataAdapter(sqlCmd)
    sqlDa.Fill(dt)
Catch ex As SQLException
    ' Ahhhh, what to do now!!!?
Finally
    connection.Close()
End Try

Answer 1

I see a lot of recommendations not to catch it if you don't know what to do with it. That's only sort of right. You should be catching exceptions, but maybe not at this level. Using your code for an example, I'd write it more like this:

Using connection As New SqlConnection("connection string here"), _
      sqlCmd As New SqlCommand("do some SQL", connection), _
      sqlDa As New SqlDataAdapter(sqlCmd)

    sqlDa.Fill(dt)
End Using

Not only is there no Try/Catch/Finally, there's no open or close. The .Fill() function is documented as opening the connection if required, and the Using block will make absolutely certain it's closed correctly, even if an exception is thrown.

This leaves you free to catch exceptions at a higher level — in the UI or business code then calls the function where your query runs, rather than right here at the query itself. This higher-level code is in a much better position to make decisions about how to proceed, what logging needs to happen or show a better error message to the user.

In fact, it's this ability for exceptions to "bubble up" in your code that makes them so valuable. If you always catch an exception right there where it's thrown, then exceptions aren't adding much value beyond the vb's old "On Error Goto X" syntax.

Answer 2

It depends on what the SQL does really. Is it something:

• that the user did? Perhaps create an account or a message - then you need to inform the user that something is wrong
• that the application does naturally? Like cleaning up logs or something similar? Is it fatal? Can the application go on? Is it something that can be ignored - perhaps retried? Should the administrator be announced?

Start with these questions, they will usually lead to answers about how to treat exceptions

Answer 3

I would consider logging that the exception took place and notify the user that you were unable to complete their request. This assumes that this SQL request is necessary to completion of the action the user is attempting to perform.

Answer 4

Rule of thumb for exception handling--If you don't know what to do with it, don't catch it.

Corollary to the rule of thumb for exception handling--Handle exceptions at the last responsible moment. If you don't know if this is the last responsible moment, it isn't.

Answer 5

What do you want to do? It depends entirely on your application.

You could have it retry, you could display a message box to the screen, write to a log, the possibilities are endless.

As a developer, you can't predict every possible error. It's a good idea to have a generic catch code in even if you don't know how to fix the error. You could be saving to a database, and one of 50 database errors might occur, and you won't be able to write code to handle every single one.

You should put a generic catch in to make sure your program doesn't simply crash, and in some cases simply displaying the error and letting them have another go is enough. Imagine if the cause was 'disk is full'. You could merely print out the exception, and let the user try again - they'd know what to do, and solve the problem themselves.

This is why I disagree with the comment about not handling it if you don't know what to do. You should always handle it, even if it is just to display a message box saying 'Error' because it's infinitely better than "This program has performed an illegal operation and will be closed."

Answer 6

If don't know how to react to it, don't catch the exception.

Catch it instead in a place where you have the possibility to handle it and where you know how to continue execution afterwards.