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?
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.
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.
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
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.