[IPython-dev] Nicer display of exceptions with ipython1

[Gael Varoquaux]

On Sun, Jul 20, 2008 at 03:52:05PM -0600, Brian Granger wrote:
> In this case, I am not sure that a callback will really do what we
> want.  One reason we have the option to allow the interpreter actually
> raise the exception is that is how Python handles errors.  If we move
> things to a callback, we sort of get stuck with our own non-exception
> based error handling.  That would be very non-ideal.

Well, I think this needs to be thought of carefully, and we probably need
the option to reraise the exception anyhow.

> I am not sure if it is possible, but I think the best solution is if
> the traceback_trap can be smart and dynamically modify the traceback
> to remove the unwanted information.  This is also needed even if the
> interpreter is not raising the exception.  In that case, the
> interpreter returns a dict that has the traceback as a string - with
> the unwanted info as well.  Conclusion:  we need to figure out a way
> of remove the unwanted info in the first place.

Hum, I thought that if you catched the exception in the very function
where the exec call lies, like it is done in ipython0 (iplib.py, line
2083), this give you a cleaner traceback with no postprocessing required.
However, there must be an additional trick that ipython0 plays. It seems
that the code is executed in a virtual module. As a result the traceback
is very clean:

In [7]: print i
---------------------------------------------------------------------------
NameError                                 Traceback (most recent call
last)

/home/varoquau/<ipython console> in <module>()

NameError: name 'i' is not defined

We need to figure out how this is done. I'll ask Fernando tomorrow.

> Also, isn't this what the callback would have to do anyway?  If so,
> that logic should just be in the traceback_trap itself.

Well, the callback could do more. In an IDE, for instance, you could have
an option to open the relevant file in an editor, or open a debugger, or
a stack inspector. This is why I am thinking of a callback. I can hardly
see how to account for all these possibilities without either resort to
some obfuscated code, or using a callback. Maybe I am missing the
obvious.

Cheers,

Gaël