[Python-Dev] short-circuiting runtime errors/exceptions in the python debugger.

[Ed Peschko]

Steve,

thanks for the response, and yes, I've experimented with reverse
debugging, and yes for the reasons specified in that article you gave
it isn't really practical with anything but small projects because of
the massive amounts of memory usage.

But that's really not what I'm asking for here. I'm simply asking that
python give developers the opportunity to stop execution and open up a
debugger *before* the exception is hit, and be able to instrument the
code at that point using that debugger.

The way that I mimic this in perl is by wrapping places where die,
confess, croak, AUTOLOAD, etc are hit with something that looks like
this:

sub _confess
{
    $DB::single = 1;
    my $trap = 1;
    if ($trap)
    {
        confess(@_);
    }
}

that way, I can short-circuit evals before they happen and save the
state to both examine and modify.

It's a hack, but it's a manageable hack since there are only so many
places where things can go off the rails in perl, and I cover each
exit. I can set $trap = 0 and lo-and-behold it will continue as if no
trap was issued.

Now, if there is global reverse debugging implemented in python, this
has got to be doable as well. I'd dare say it could be done with very
little overhead in memory.

> You know you can set breakpoints in the debugger? You don't have to
> single-step all the way through from the beginning. It isn't clear from
> your post how experienced you are.

ok just to be on the totally clear side, yes I'm quite aware of
pdb.set_trace(), etc.

They however don't do much to help the pain of debugging and
maintaining code which is *not your own*. For all good they are, you
might as well step through each line because you have no clue where
the mines in a particular script or library reside, and when you are
going to hit them.

And of course depending on how good the debugging implementation is,
when you hit these mines they may be well-nigh impossible to remove
without something like this.

Which btw is the main reason WHY I'm asking for this, and this is why
I think it would be such a productivity booster. Not for my code which
I control, but for others.


I'll take one particular experience here to make my point. I've been
experimenting with an automation framework written in python here that
shall otherwise remain nameless (except it is a fairly popular one).

Its ssh layer is *notoriously* obtuse, it freezes up on multiple
occasions,the support lists are clogged with issues surrounding it,
yet release-after-release things don't get fixed. Why? I'd argue
because the code is hard to parse but even harder to debug. Having
something like this would be a great boon to fixing any such issues.

So that's basically it.

No - I'm not looking for a full-blown reverse debugger for the reasons
you state. I'm looking for something more limited and therefore more
workable.

Ed