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'd like to suggest to you that if you do not know what to do with an exception, do not catch it. Too often, coders catch exceptions and just swallow them whole.

catch (Exception ex)
{
  /* I don't know what to do.. *gulp!* */
}

Clearly this isn't good, because bad things are happening, and no action is being taken. Only catch exceptions that are actionable!

That said, graceful error handling is important. Don't want your app to crash, right? You may find ELMAH useful for web applications, and a global exception handler is pretty easy to set up for WinForms or XAML desktop apps.

Putting all that together, you might find this strategy useful: 1. catch specific exceptions that you know might occur (DivideByZeroException, SQLException, etc.) and steer away from the generic catch-all Exception; 2. re-raise the exception after you handle it. e.g.

catch (SQLException ex)
{
  /* TODO: Log the error somewhere other than the database... */
  throw; // Rethrow while preserving the stack trace.
}

What can you really do with an SQLException? Did the database connection disappear? Was it a bad query? You probably don't want to add all the handling logic for that, and besides, what if it's something you didn't expect? So just handle the exception if you can, re-raise it unless you're certain it's resolved, and gracefully handle it at a global level (e.g. Show a message like "Something went wrong, but you might be able to continue working. Detailed info: '[ex.Message]'. Abort or Retry?")

HTH!

John Saunders, thanks for the correction.

Answer 2

Unless you were expecting the error (the API says it can occurr) and can handle it (there is an obvious step to take if the exception occurrs), you probably want to crash with a lot of noise. This should happen during testing / debugging, so that the bug can get fixed before the user sees it!

Of course, as commenters have pointed out, the user should never really see all this noise. A high-level try/catch or some other method (EMLAH, I hear for .net web projects) can be used to show the user a nice error message ("Oops! Something went wrong! What on earth were you trying to do?") with a submit button...

So basically, my point is this: Do not catch errors you don't know how to handle! (except for the high-level handler). Crash early and with as much information as possible. This means you should log the call stack and other vital information if at all possible for debugging.

Answer 3

First, if there is no way for your application to handle the exception then you shouldn't catch it in the first place (logging can be done via exception event handlers without catching).

If there is something you can do then do that. For example, roll back the transaction and report it failed to the user. This is going to depend on your application.

Answer 4

It depends entirely on context. Possible options include "Use default data instead of data from the database" and "Display an error message to the user".