That is the point of debugging your code. By reducing your code to a small snippet, you stepwise eliminate all unrelated parts. And usually, if the symptom goes away between two editions of your program, it is highly likely that the part you changed last is related to the symptom.--- When my code was significantly simpler, that was the case, but having spend enough time in the kernel and in other real-time systems, 9 times out of 10, changing a line of code and seeing a change in behavior were unrelated because the underlying trigger was 1000's of lines away in code that seemed to work perfectly in all other cases.
Case in point was a kernel hang -- would run for up to days w/no problem, then hang, so finding 1 line to change out of 5000 and waiting for days wasn't the most ideal solution for debugging. in fact trying to break apart pieces only led to management thinking that there really was no problem or that the product should be released anyway -- because pieces would work. It was only when all the subsystems were tied together than one subsys relying on annother that called a third didn't release a deeply held lock -- so after the damage was done, only rarely would the locks go that deeply and hit the 'stuck lock'....
I could detail about 10-20 other similar situations, where none of them were simple bugs -- I was given these problems to solve because they weren't easy and couldn't be solved by simplification and simplification was only a waist of my time (not that I didn't try where possible). The one that froze every few days - I optimized the hell out of the code so it froze < 2-3 hours... then finally down to <45 minutes. My manager was pissed at me spending so much time optimizing, but when I got it to happen frequently enough, I was able to catch it in the act and finally solve the problem. Insisted on a full 7-day run-test as proof that the bug was gone...it passed, and I got downgrade my next review for wasting time optimizing the product and requiring too long for testing.
Generally, I've been trying to use perl as a higher order language, but that's when the slightest variance in my understanding and how it really works (right or wrong) leads to big brokenness later on.
Because of such, I try to add in lots of error checking and debug support routines with the result that my programming goes alot slower than most - a recent program in perl of around 2k lines as probably, easily 1k lines dedicated to debugging and error checking -- note I say easily 1k, my gut wants to say about 2/3rds or more went into error checking...boy does that slow down your coding....but it does help in narrowing down the location of problems more quickly, later...
-linda
In reply to Re^4: How do you find keys of a Blessed Hash?
by perl-diddler
in thread How do you find keys of a Blessed Hash?
by perl-diddler
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |