If I were you, I'd make the breakpoint conditional from a global variable.

update

something like $DB::single = BREAK should do, like this BREAK can be either a constant or even a function.

activation of BREAK() can be done when starting up the debugger

When perl5db.pl starts, it reads an rcfile (perl5db.ini for non-interactive sessions, .perldb for interactive ones) that can set a number of options. In addition, this file may define a subroutine &afterinit that will be executed (in the debugger's context) after the debugger has initialized itself.

If your are running the debugger interactively (with the -d option), you could continue the run with the c command instead of restarting.

If the script is run without the debugger, the line $DB::single = 1; has no effect (but causes a warning with -w), so I have some difficulty to recognize the merits of this method.

Obviously you could grep for $DB::single in your Perl sources to find any left-overs...

BTW: I am using an automatic breakpoint to catch the cause of any warnings during a run under the debugger. That is, whenever I get a warning about an undefined value being used in an addition for example, I let the debugger stop right there, so I can investigate the context that led to this behavior. The original source does not need to be modified (see here for details).

If your are running the debugger interactively (with the -d option), you could continue the run with the c command instead of restarting.

Yes, but my point is that I arrive on that BP in a loop, after a long processing. Sure I can continue, but if the loop is iterating 10_000 times, I won't type 10_000 times c+enter.
That is why I asked if there could exist a useful incantation to skip the problematic BP.

And many thanks for that trick of automatic breakpoints. I did not know that a warning at runtime was throwing a signal to the process that can be managed.

Look the breakpoint is set at runtime!

... you are free to code whatever you want to control it.

Like using a sub dbbreak()

sub dbbreak {
   $DB::single = $DB::my_single_breaks_allowed;
}
[download]

would not only make your code more readable and it'll give you full flexibility for future changes.

update

if you make sure that setting $DB::single is the last command in the sub, then your break will happen after returning!

just tested

$DB::debugger_breaks_allowed =1;


sub break_db {
   $DB::single = $DB::debugger_breaks_allowed;
#   print "inside";
}


print "before";

break_db();
print "after"; #<-- breaks here

print "later";
[download]

And grepping your old code for $DB::single for replacement shouldn't be too problematic...

Cheers Rolf
_{(addicted to the Perl Programming Language and ☆☆☆☆ :)
Je suis Charlie!}

ok, maybe you can replace the hard coded breakpoints with
• either a conditional breakpoint like this

  if (some interesting abnormal condition) {
          $DB::single = 1;
  }
  [download]

  (if you need them permanently in your code). This should trigger only when something is not as expected (so hopefully seldom).

• or debug with the automatic breakpoint method, I mentioned in my first reply.
• or use a conditional breakpoint from the debugger (b [line] [condition] from Debugger Commands)