[Python-Dev] short-circuiting runtime errors/exceptions in python debugger.
I have another idea on this. What about the idea of starting the program,
and then a few minutes later, starting the same program a second time. If
the first program errors, you could examine the second one which is a
little bit behind. Before starting the second one, perhaps you could even
make a copy of the second one and pause it for a few minutes before
restarting, in case the second one also errors out, and so on. This would
be more useful only in the case of deterministic errors.
On Mon, Oct 29, 2018 at 11:59 AM Chris Jerdonek <chris.jerdonek at gmail.com>
> A simpler feature that could possibly help him (assuming there isn't any
> external state to deal with) would be the ability to save everything at a
> certain point in time, and then resume it later. He could rig things up to
> save the state e.g. after every hour: 1 hour, 2 hours, etc. Then if an
> error occurs after 2.5 hours, he could at least start resuming after 2
> hours. This could be viewed as a cheap form of a reverse debugger, because
> a reverse debugger has to save the state at every point in time, not just
> at a few select points.
> On Mon, Oct 29, 2018 at 9:51 AM Armin Rigo <armin.rigo at gmail.com> wrote:
>> On Sat, 27 Oct 2018 at 01:50, Steven D'Aprano <steve at pearwood.info>
>> > [...]
>> > > So I was wondering if it would be possible to keep that context around
>> > > if you are in the debugger and rewind the execution point to before
>> > > the statement was triggered.
>> > I think what you are looking for is a reverse debugger also known as
>> > a time-travel debugger.
>> I think it's a bit different. A reverse debugger is here to debug
>> complex conditions in a (static) program. What Ed is looking for is a
>> way to catch easy failures, fix the obviously faulty line, and
>> continue running the program.
>> Of course I can't help but mention to Ed that this is precisely the
>> kind of easy failures that are found by *testing* your code,
>> particularly if that's code that only runs after hours of other code
>> has executed. *Never* trust yourself to write correct code if you
>> don't know that it is correct after waiting for hours.
>> But assuming that you really, really are allergic to tests, then what
>> you're looking for reminds me of long-ago Python experiments with
>> resumable exceptions and patching code at runtime. Both topics are
>> abandoned now. Resumable exceptions was a cool hack of the
>> interpreter that nobody really found a use for (AFAIR); patching code
>> at runtime comes with a pile of messes---it only works in the simple
>> cases, but there is no general solution for that.
>> A bient?t,
>> Python-Dev mailing list
>> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...