This thought was triggered by reading C/C++ type assert() in Perl?.

I use the debugger when I have to. Which generally speaking is fairly rarely. I'm quite comfortable using CLI debuggers, having started doing so when there was literally no alternative; programming in assembler. Perl's debugger is really very powerful and very convenient to use--once you get to the point you need to be at--it's getting there that is the problem.

There are various techniques for running to particular places in the code. Breakpoints, watches etc. The problem with them is that you have to re-type all your commands once you made a change. Yes, you can load commands from a file, but there's no really convenient way to save them to a file once you interactively decided what sequence of commands is required to get you where you need to be. CL histories don't help much either because they also tend to keep all the stuff that wasn't useful.

Long story short: Is there any perl equivalent of the int3 instruction?

Something that will drop you into the debugger when it is encountered in the source at the point that it is encountered so that you can easily continue debugging from that point?

I've tried die, but by that point the internal state is screwed.

What's needed is a way to tell the debugger to run the program non-interactively until the "int-3" instruction is encountered and then break into the debugger at that point. It should be possible to add a line like

...
int3 if not exists $hash{'thing'} or $hash{'thing'} ne 'something';
...
[download]

Then perl -d=go script.pl and the program runs normally (if slowly) until one of the int3 assertions is true.

Is there already a way to do this easily that I have missed?

If not, can anyone see an easy way to implement it?

Does anyone else think that this would be useful?

Clarification:

Stated another way, what I'm looking for is a simple mechanism to effect a breakpoint, from with the perl source that will drop me into the debugger when it is encountered. And do so such that the environment in place when the breakpoint is encountered, is still intact. As it would be if I had added the breakpoint via the degugger command line but is not the case with die or carp.

This way I can investigate the reason why things are not as they should be. Inspect variables, change the values etc. and then continue the program to see if I've found and fixed the cause. This is also not possible after a die or Carp.

Essentially, I am looking for a way to embed debugger commands directly in the source rather than issuing them from teh debugger prompt or putting them into a separate debugger script.

It just seems it would easier, more natural and intuative to maintain debugger commands in-place in the script being debugged. That way, you don't have to adjust the line number on breakpoint every time you add or remove a line. Changing the conditions on break and watch points as you home in on the source of the problem is much easier if the changes are located in the context of the code rather than in a separate script or trying to remember them each time you re-run the debug session.

Does that make any sense to anyone else?

20040611 Edit by Corion: Fixed runaway <i> tag