I've caught an exception!! Now what?

2020-05-19 10:58发布

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

16条回答
ら.Afraid
2楼-- · 2020-05-19 11:25

If you don't want to do anything with it, you can always just do try/finally rather then try/catch/finally

查看更多
叛逆
3楼-- · 2020-05-19 11:28

It depends on your business logic, but you may want to do one or more of the following.

  • Rollback your transaction
  • Log the error
  • Alert any user of the application
  • Retry the operation
  • Rethrow the exception

You may also wish to check if the exception is of a type you can handle before one of the above.

A good article on VB.NET exception handling is Exception Handling in VB.NET by Rajesh VS.

查看更多
家丑人穷心不美
4楼-- · 2020-05-19 11:31

One thing to keep in mind is that in sections where you feel you do want to use a try/catch, you should move your Dim statements out of the try block. You can assign them values inside the block, but if you define them inside the try block, you won't have access to those variables inside the catch section as they will be out of scope at that point.

My standard practice in catch blocks, including trying to remediate the error if possible, is to write out to whatever logging mechanism I am using information about key variables that were involved in the section causing the error. It's not necessary, but I've found it often helps with debugging problems.

查看更多
5楼-- · 2020-05-19 11:32

Well, That depends primarily if you are making money from your application or not. By my experience, nobody (who paid for an application) likes to see it crashing and closing, instead they prefer a short and explanatory message about the error and a second chance to continue whatever they were doing plus a chance to save/export their modified data. IMO a best practice is to catch everything that can cause something wrong out of your control, like I/O operations, networking related tasks, e.t.c. and display a relevant message to the user. In case that an exception is thrown due to a logic related error is better not to catch it since this will help you to find and correct the actual error.

Hope this helps.

查看更多
Evening l夕情丶
6楼-- · 2020-05-19 11:33

FYI, you don't have to use the catch to have a finally statement.

Sometimes people throw a new exception that is more firendly and add the original exception as the inner exception.

Often this is used to log the error to a file or send an email to an operator.

Sometimes, especially with SQL, it may just mean a duplicate key which means, for example, please choose another username, that one is already taken - it's all down to your application.

查看更多
戒情不戒烟
7楼-- · 2020-05-19 11:33

Depending on the type of application, consider either a global logging handler (i.e. 'Application_Error' for ASP.NET applications) or using a pre-built open source or MSFT provided exception handling framework.

The Exception Handling Application Block as part of the Enterprise Library 5.0 is a suggested framework to use.

Aside from logging, I agree that exceptions need not be explicitly caught unless you need to do something meaningful with them. And the worst mistake is just to 'Catch' and then 'Throw' again as this messes the StackTrace up.

查看更多
登录 后发表回答