What is the quickest way to isolate the source of an error amongst a list of potential sources?

Question

What is the quickest way to isolate the source of an error amongst an ordered list of potential sources? For example, given a list of column mappings, and one of those column mappings is incorrect, what debugging technique would lead you to most quickly identify which mapping is invalid? (By most quickly, I mean, which approach would require the fewest compilation, load, and run cycles?)

Assume that whatever error message the database or database driver generates does not identify the name of the errant column. Sound familiar?

Hint:

The technique is similar to that which you might use to answer the question, "What number am I thinking of between 1 and 1000?", but with the fewest guesses.

Answer 1

Sounds familiar, but I hate to be the one to tell you that there is no "quick" way of isolating the sources of errors. I know from my own experience that you want to be absolutely sure you've found the correct source of error before you go about resolving it, and this requires plenty of testing and tracing.

Answer 2

Keep adding more and more diagnostic information until I either isolate the issue, or can't add anymore. If it's my code vs. external code, I will go crazy with trace statements until I isolate the critical bit of code if I otherwise don't know where the issue is. On Windows, the SysInternals suite is my friend... especially the debug viewer. That will show any trace statements from anything running on the system that is emitting trace.

If I truly cannot get more specific information from the error source, then I will go into experimental mode... testing one small change at a time. This works best if you know you have a case that succeeds and a case that does not.

Trivial example: If I have row X that won't be inserted into the database, but I know row Y will, I will then take row Y and change one field at a time and keep inserting until row Y's values = row X's value.

If you really are stumped at where the issue is coming from, time to dust off your Google-fu skills. Someone has probably run into the same problem and posted a question to a forum somewhere. Of course, that's what SO is for too.

You're the human... be more stubborn than the computer!

Answer 3

You can use interpolation in some cases. I've used this successfully to isolate a bad record.