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