I've actually thought of it. I'm thinking of adding a small script that would filter out any calls to DEBUGGER subroutines as well as the 'use DEBUGGER ...' clause.
I'm also thinking of changing name from 'brake' to
something like '__break' (or even '__breakpoint') to show explicitly the 'temporary' nature of those statements. In any case, a filter script shouldn't be hard to write ;-).
Referring to tilly's mentioning of lack of use for a debugger, I think that I wouldn't be able to render an absolute answer. It may be true in one case.. whereas it may not in other. I generally prefer to first start with simple print statements and error logging (into a log file & STDERR as an option). And only if this doesn't work, I use 'perl -d'. At times, I find using a debugger is extremely easy. I simply set a break point (conditional if required) at any given suspicious spot in my program and let debugger execute my script until the breakpoint is reached. Also, by limitting raw data (input etc.) I'm able to force the script get to the marked (breakpoint) line relatively fast. Once the breakpoint is reached, I trace through a few lines, checking for current program data integrity etc. One excellent feature of perl debugger is that it allows me to manipulate program data on the fly as well as execute arbitrary lines of code (even something i make up and which isn't really present in the source file). This way, I might even test a few variations of a particular statement to see how it would solve the problem etc. I've been using perl debugger since almost the first day I read my first perl book. And I should say, it really helped me dig into the root of a number of abnoxious problems in a much shorter time than it would have taken me had I used other conventional means of debugging (print statements and error logs). Although, obviously two approaches are handy given particular situation.
|
"There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith
|
| [reply] |
I build in a option of $verbose. This means I print out statements if $verbose. If I set $verbose to 0 I don't see the verbose output anymore.
I'm like tilly, I work on a test environment with a smaller dataset then on production.
I also break down the code to small subroutines I can test seperated. So afterwards when I do the whole integration test of my application, it's a test if the logic is right and not if I made a perl mistake...
--
My opinions may have changed,
but not the fact that I am right
| [reply] |
I build in a option of $verbose. This means I print out statements if $verbose. If I set $verbose to 0 I don't see the verbose output anymore.
I use something similar. I sometimes have lots of if $debug statements if I need them. Once I'm finished I can delete them if I want.
I also break down the code to small subroutines I can test seperated. So afterwards when I do the whole integration test of my application, it's a test if the logic is right and not if I made a perl mistake...
This is also crucial. I always test the function that I've written against various boundary conditions and then integrate into the whole otherwise you get horrendous error messages in your program.
Plus my two cents with regards to debuggers....I've done both print statements and have used a debugger and I have to say that I prefer print statements! I've always found debuggers a pain to use but YMMV.
metadoktor
"The doktor is in."
| [reply] |