I don't think there's ever a need to fire up the debugger
We support a large and complex product, running in many different countries, written in multiple languages, mostly C++. Whenever one of our executables crashes, our software automatically creates a crash dump file. When one of these crash dumps arrives in my in-box, I load it in the debugger (with matching symbols) to try to understand the root cause of the crash. Does that qualify as having a "need" to fire up the debugger?

I might add that attaching a debugger to crash dumps is sometimes insufficient to solve the problem, for example when a program crashes because it attempts to access an object that has already been deleted ... which is why we also have a home-grown logging system (similar to Log::Log4perl) so we can see the history of events leading up to the crash.

I agree with you that a debugger is just one tool among many, and will sometimes be the most effective tool for the job. The main reason I tried to curb the OP's enthusiasm for the debugger is because I looked at his code.

I occasionally work on code written by someone who has retired. Code which doesn't have unit tests and/or isn't well designed and/or hasn't been touched in a decade or so. I could, of course, just argue it's not maintainable (merlyn). But when I'm interested in the code, I'd rather spit into my hands and grab whatever tools might help.
Yes, I agree merlyn took an extreme position - perhaps he is one of the few programmers in the world who could challenge the Joel Spolsky wisdom "It's important to remember that when you start from scratch there is absolutely no reason to believe that you are going to do a better job than you did the first time". Or perhaps he was dealing with smallish systems. Rewriting crap from scratch quickly becomes untenable once you go past a million lines of code. BTW, I keep a list of references on the difficult topic of dealing with legacy code.

Your liking of the transient nature of debugging sessions baffles me (I may have misunderstood your intent). After all, large successful software is written by teams, over many years ... so I feel it is our duty when faced with nasty debugging problems to make the code better and easier to maintain for our teammates and for those who maintain our code after we leave ... so throwing away the hard-earned insights from an individual's transient debugging session seems unprofessional to me. At a minimum, I would expect some judicious comments and logging that stay with the code.

In reply to Re^5: Using the perl debugger to look at a renaming files function (Remote Support) by eyepopslikeamosquito
in thread Using the perl debugger to look at a renaming files function by Aldebaran

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.