Hi folks,
I've started using try catch blocks (bit late i know!) but now im not sure what to do with the exception once i've caught it. What do people usually do here?
-- Jonesy
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
What do you want it to do? It depends entirely on your application.
You could have it retry, you could display a messagebox 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 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 messagebox saying 'Error', because it's infinitely better than "This program has performed an illegal operation and will be closed."
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.
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".
If you don't want to do anything with it, you can always just do try/finally rather then try/catch/finally
It depends on what the sql does really. Is it something:
Start with these questions, they will usually lead to answers about how to treat exceptions
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.
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.
1st 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. e.g. roll back transaction and report it failed to user. this is going to depend on your application
depends on your business logic but you may want to do one or more of the following:
You may also wish to check if the exception is of a type you can handle before one of the above.
There is a good article on VB.NET exception handling here:
I see lots of other people have had a go at answering this in the mean time, I would recommend asking another question, and describing exactly what you are trying to achieve...
Rule of thumb for exception handling--If you don't know what to do with it, don't catch it.
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.
FYI You dont 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 eg please choose another username, that one is already taken - its all down to your application.
Hi Jonesy,
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 a 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.