[Python-ideas] Function arguments in tracebacks

[Brett Cannon]

My quick on-vacation response is that attaching more objects to exceptions
is typically viewed as dangerous as it can lead to those objects being kept
alive longer than expected (see the discussions about richer error messages
to see that worry come out for something as simple as attaching the type to
a TypeError).

On Tue, 27 Dec 2016 at 09:26 Ammar Askar <ammar at ammaraskar.com> wrote:

> Consider the following similar C and Python code and their
> tracebacks:
>
> C
> -------
>   int divide(int x, int y, char* some_string) {
>       return x / y;
>   }
>   int main(...) {
>       divide(2, 0, "Hello World");
>   }
> -------
>   Program received signal SIGFPE, Arithmetic exception.
>   (gdb) bt
>   #0  0x00000000004004c4 in divide (x=2, y=0, some_string=0x4005a8
> "Hello World") at test.c:2
>   #1  0x00000000004004e7 in main (argc=1, argv=0x7fffffffe328) at test.c:6
>
> Python
> -------
>   def divide(x, y, some_string):
>     return x / y
>
>   divide(2, 0, "Hello World")
> -------
>   Traceback (most recent call last):
>     File "test.py", line 4, in <module>
>     File "test.py", line 2, in divide
>   ZeroDivisionError: division by zero
>
>
> By including the function arguments within the traceback, we
> can get more information at a glance than we could with just
> the names of methods.
>
> This would be pretty cool and stop the occasional "printf"
> debugging without cluttering up the traceback too much.
>
> There will definitely need to be some reasonable line length
> limit  because the repr() of parameters could be really long.
> In similar situations gdb replaces the value in the traceback
> with elipsis, and I believe that's a good solution for python
> as well.
>
> Obviously this isn't a great example since the error is immediately
> obvious but I think this could be potentially useful in a bunch
> of situations.
>
> I've made a a quick toy implementation in traceback.c, this is what
> it looks like for the script above.
>
>   Traceback (most recent call last):
>     File "test.py", line 4, in <module>
>       divide(2, 0, "Hello World")
>     File "test.py", line 2, in divide (x=2, y=0, some_string='Hello World')
>       return x / y
>   ZeroDivisionError: division by zero
>
>
> == Potential Downsides ==
>
> There's probably a lot more than these, but I could only think of
> these so far.
>
> * Private data might be leaked, imagine a
>
>     def login(username, password):
>         ...
>
>   method. While function names/source files/source code are also
>   private, variables can potentially contain all kinds of sensitive data.
>
> * A variable that takes a long time to return a string representation may
>   significantly slow down the time it takes to generate a traceback.
>
> * We can really only return the state of the variables when the
>   traceback is printed, this might result in some slightly un-intuitive
>   behavior. (Easier to explain with an example)
>
>     def f(x):
>        x = 2
>        raise Exception()
>
>     f(1)
>
>   Traceback (most recent call last):
>     File "<stdin>", line 1, in <module>
>     File "<stdin>", line 3, in f(x=2)
>
>   The fact that x is mutated within the function body means that the
> value printed in
>   the traceback is the changed value which might be slightly misleading.
>
>
> I'd love to hear your guy's thoughts on the idea.
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20161228/0f1e47a1/attachment-0001.html>