On exception pudb now jumps into the exception instead of showing it

[shaoran]

Describe the bug

When you set a breakpoint with pudb.set_trace() and pudb stops, you can press n to execute the next statement. In the past if you the statement raised and exception, pudb would tell you that an exception was raised and pressing e let you inspect the exception. Since the release v2022.01.02 pudb does not show the exception but instead jumps onto the function where the exception was raised.

To Reproduce
Steps to reproduce the behavior:

1. create a function that has raises an exception
2. write a function that calls the failing function and set a break point before the call with pudb.set_trace()
3. Press n to execute the failing function

Expected behavior

pudb should tell you that the function raised an exception, by pressing e you should be able to inspect the the exception

Additional context

While some some might consider thus a nice feature, it also has the huge drawback, that it takes out of the context you were debugging and you might not be able to jump back, specially on asyncio tasks where you end up on the aio-loop rather than on your initial breakpoint.

I already asked this question on the discussions board and it was suggested that I do a git-bisect. I did that and 98ccafc was found as the commit that introduced the bug.

Versions

• v2022.01.02 on Python 3.10.4

[inducer]

The regressing change was introduced in #515 to address a duplication of stack content in post-mortem mode. A PR satisfying both goals would be welcome.

[shaoran]

@inducer I'd love to do that, but I have no clue how pudb internally works. I also read #515 but I don't understand it and I also don't know why

if tb is not None:
    frame = None

leads to the UI jumping into the statement that raises the error.

[shaoran]

I'd like to understand more why the regression was introduced in #515 because this is driving my crazy.

On this example:

import asyncio
import sys 
import pudb

async def has_an_error():
    print("This function has en error")
    a = {}

    b = a["b"] + 1 

    return b


async def main():
    pudb.set_trace()

    try:
        n = await has_an_error()
    except asyncio.CancelledError:
        raise

    print("n =", n)

if __name__ == "__main__":
    sys.exit(asyncio.run(main()))

If I execute python /tmp/error.py, then I i jump into line 9 after pressing n twice. If I just press c for continue, pudb exists, the script continues and I get the exception on stderr when the script finishes.

However, if I start it as pudb /tmp/error.py (and comment out the line 15 with pudb.set_trace() and the press c, then pudb stops at line 9 and show me the exception and give me the OK and Save traceback options. If I select OK, I see on the top of the bar a POST-MORTEM MODE, and here I finde OK that it jumped into line 9.

So my question is, is there a way that pudb.debugger.Debugger.get_shortened_stack() realizes whether it's running because it was started via pudb.set_trace() or via the command line? In the former case, the if tb in not None: frame = None should not be executed thus restoring the behaviour of <=pudb-2022.1?

That's why I want to know when you enter into the post-mortem mode? Or could get_shortened_stack() recognize whether it's on post-mortem or not? I'm afarid I don't really understand the internals of pdb or pudb and don't know how to such a check.

[shaoran]

So could this be a solution?

def get_shortened_stack(self, frame, tb):
    if if tb is not None and self.post_mortem:
        frame = None
   ...

?