1

Closed

What exactly does "User-unhandled" exception mean?

description

The PTVS documentation indicates that "User-unhandled" means that there is no "catch" active for the exception at the point that it is raised. It also indicates that the debugger does not know about any catch handlers in byte code without source code.
I would like to know if an exception is considered by the debugger as user handled in the following special cases:
  1. A handler does exist in native code for the exception.
  2. A handler with Python source exists but the handler contains a plain raise statement.
    Personally, if the re-raise of the exception is not handled, then I would like to break at the point the exception was originally raised, rather than break at the point where it was re-raised. I invite comments on this point.
    Also, as a feature suggestion, I would like to see all exception handlers be detected, including those in byte code without Python source and in native code.
Closed Jan 20 at 5:53 PM by Zooba

comments

Zooba wrote Dec 20, 2013 at 9:08 PM

  1. No, we can't detect these. It would involve disassembling native code and detecting a comparison against NULL, which is impossible to get right.
  2. This is considered to be handled, and we'll continue, but then the raise statement is considered new, so if there is no further handler we will break there.
Detecting handlers in bytecode may be possible, though it's an implementation detail of CPython that we wouldn't want to rely on. Native code is not going to happen.

As for a definition, "user unhandled" means "not handled in the user's code" - this came from other VS languages so we use the same definition for consistency. Because we only "care" about the user's code, we assume that source code is available and if not, then an exception is escaping. In the context of frameworks, and especially native frameworks, this may be okay. Python also reports exceptions for control flow that we think are user unhandled because the handler is in native code (StopIteration and GeneratorExit for example). Because of the way Python handles exceptions and stack unwinding, this is the best we can do, which is why the options are there to turn it off.

Languages like C# have similar issues, though because we (Microsoft) control the compilers we can emit extra information to improve it. In Python we don't have that luxury (also why there's no edit and continue functionality).

I hope that's cleared things up a bit. Thanks for your interest and please find ways to contribute, but I don't think there's much available to do in this area.