[Python-3000] Exception tracebacks and PEP 3101

[Patrick Maupin]

On 3/6/07, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> Patrick Maupin schrieb:
> > I'm a newbie when it comes to deep Python internals, so maybe I'm
> > missing something obvious.  I'm trying to figure out the right answer
> > for exceptions/tracebacks in PEP 3101 (advanced string formatting).
>
> You should turn the question then around: "This is what I want to
> display, how can I achieve that".

That was a statement.  The question comes later :)

> This seems the tricky part here: What *is* it that you want to
> display?

The obvious, greenfield, blue-sky, non-pre-existing-implementation,
perfect-world thing to do is to add a record to the stack traceback.
This record would be in a different language than Python (it would be
in the "format string" language), and would contain location
information relevant to that different language that would help the
exception system display a snippet of the format string that would be
useful to the programmer.

Just like the exception and any other stack trace information, this
trace record could be printed out to stderr by default, or otherwise
manipulated, displayed, analyzed, etc. programmatically, or even
ignored by a try/except statement.

>
> > However, it seems that the Python traceback scheme is intimately tied
> > to the concept of Python execution frames, which are assumed to have
> > associated text information from a file.  I'm not sure that I can
> > legitimately add to a preexisting traceback from a C function in a
> > non-fragile fashion.  Even if I could, I don't really have a "file" to
> > show the user (unless I dynamically create one).
>
> You can certainly add a stack frame into the traceback, see
> Modules/pyexpat.c (call_with_frame). However, this will get you just
> a function number, line number, etc: there is no exception object
> associated with the trace.

That's useful information.  I might play with this even though it's
not exactly what I would like to see (I could dummy up the function
name to be something related to the failing lcoation in the string,
for example.)

>
> > So it seems the only answer might have to have options like "let the
> > user see the existing traceback" or "get rid of the traceback and
> > raise an exception which shows exactly where in
> > the format string the error occured",  or "print the preexisting
> > traceback to stderr, then toast it and raise a new exception showing
> > the string location in the exception text."
>
> I still don't understand why you worry about the stack trace. Isn't
> the exception object what you are after?

In the current implementation, probably.  In the best possible world,
certainly not.  The exception is whatever it is .  That's not my deal.
 All I really want to do is leave a breadcrumb on how we GOT to the
exception to help give a clue to the poor slob who's up at 3:00 AM
trying to find that last bug.

> > I guess there are two parts to my question:
> >
> > 1) What is the best thing to do right now for PEP3101?
>
> I may be repeating myself, but I think you are looking for some kind of
> nested exceptions. There is no notion of nested exceptions yet in
> Python, but you could try to implement some scheme, where the formatting
> exception has a reference to the "true" exception, and, when printing
> the formatting exception, the true exception and its traceback get printed.

I agree that nested exceptions may be the best I can do in the current
implementation, and I can (and probably will) do what you and Talin
have independently suggested.

> > 2) If the "right now" answer isn't very good, is this really a more
> > general problem that needs work?  As more "little languages" do things
> > like manipulate the AST, it might become very useful to have the
> > ability to place almost arbitrary objects on the traceback stack.
>
> Same question again. The stack trace seems irrelevant in this problem to
> me, and so does 'putting objects on it'.

Again, the exception is the thing that happened at the bottom.  The
stack trace is a clue as to how you got there.  Nested exceptions are
a workaround.  The ideal situation would be to have a more flexible
stack trace that let you show "how you got there" through execution of
code that isn't Python, and even through execution of dynamically
generated Python code that has no associated file object (but which
may have an associated string object, for example).

Regards,
Pat