|
|
|
|
I was recently asked a couple of questions about debugging code in Visual Basic. One cause for confusion was in a class I had written - this was trying to make connections to a database using an encrypted password. If the password failed then a plain text version was to be tried instead. Anyway - This was achieved by trying to create the first connection and checking the Err object for an error. All was fine and dandy until a colleague tried the code on their machine and it kept dropping them into VB with an error message and the option to debug or end. This was caused due to Visual Basics default error trapping mode being Break in Class Module
Regardless of if the error is trapped (as in my case) or not, VB will stop at that error. This is great if you have a class that you think might have an error in it that is not being handled correctly and this is stopping the rest of your application functioning correctly. However this is a major pain if you are using classes that have been fully tested already. The answer? Change the error trapping to Break on Unhandled Errors. This will gladly process code that is error handled correctly but stop at an unexpected error. Do you think that the error handling might not be working as originally intended? Setting trapping to Break on All Errors will at least give you the opportunity to see those cases where errors are occurring and being handled. You might not even have realised that an error was occurring there and that the handling wasn't quite right. This can be a quick way to solve some really tricky to find errors. |
|
Last updated insert_Date |
