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

[Chris Jerdonek]

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.

--Chris


On Mon, Oct 29, 2018 at 11:59 AM Chris Jerdonek <chris.jerdonek at gmail.com>
wrote:

> 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.
>
> --Chris
>
> On Mon, Oct 29, 2018 at 9:51 AM Armin Rigo <armin.rigo at gmail.com> wrote:
>
>> Hi,
>>
>> On Sat, 27 Oct 2018 at 01:50, Steven D'Aprano <steve at pearwood.info>
>> wrote:
>> > [...]
>> > > 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[1] 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,
>>
>> Armin.
>> _______________________________________________
>> Python-Dev mailing list
>> Python-Dev at python.org
>> https://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> https://mail.python.org/mailman/options/python-dev/chris.jerdonek%40gmail.com
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20181029/2777c2c1/attachment.html>