Debugging – part deux
In the not so distant past I was bold enough to call Jan and Patrick whiners. But currently I have to extend an application with some functionality and I’ve been debugging it for a few hours now. Overall it’s not that bad, but the things you can come across really make you wonder.
Dim Active As Integer
Active = 10
Select Case Active
Case TriState.UseDefault ‘ -2
‘ Do Something
Case TriState.True ‘ -1
‘ Do Something else
Case TriState.False ‘ 0
‘ Do Something else
As you can see in the code above, someone decided to use Active as a variable to store some number. After passing it through some methods, they match it against this weird enumeration from the Microsoft.VisualBasic namespace. Even though it’s an enumeration, it’s still totally unclear what it stands for.
My problem was, that this little (cut-down) piece of code was in a method that was adding SqlParamaters into an array. But as you can see in my example, when you insert the number 10 into Active, it won’t get processed, and thus the array will have a SqlParameter that’s null. When some more methods later this is added into the Microsoft Data Access Application Block (yes, the old one), it throws some weird error.
Part of the problem was the setup of the solution. I first tried to figure out what was happening with Reflector, but didn’t get it. So I rearranged the solutions (yes, multiple), added the Data Access Block and debugged my way through. Only to find out that in my array, SqlParameter number 7 was empty. So after too much time, I could not resist but make the following comment in the code. Although the original developer probably will never read it, it still feels good to get it out of my system this way! 😉
‘ Comment : Any idea why this doesn’t always work?!
‘ Any idea how long it took me to figure out the fault was in here?
‘ So I added a Case Else here, only hoping the UseDefault really
‘ is some sort of weird default, and that it now always works. >-(