And if repr (or str) has a bug, now you are chasing two issues! Besides, repr (or str) may take a lot of processing time and it is not unusual to log an exception stack trace but keep running.
At last, if you are going to debug, a lot of times is better to use a debugger instead of putting print (or log) statements all around. I prefer pydev for this. You can even attach to a python process running as a different user or even on a different computer.
I documented how to do it in a post on my blog (sorry, in Spanish). http://aurelianito.blogspot.com.ar/2013/05/debugueando-en-ro...
Once I wrote a __str__ method on a class which got into an infinite loop :) When I showed the traceback to an advanced developer, he told me immediately what was happening. How could we figure out the problem if my __str__ was broken and traceback would fail?
Also recently I struggled with py.test which automatically does that (calling str() on every local variable in the test case) but it is broken, so py.test showed me strange Unicode Decode exceptions (it turned out, nothing wrong was in my code but py.test) and I had no idea what was going on. Took me hours to figure it out py.test has a issues with __future__ unicode_literals...
tl;dr: not a good idea
import ipdb; ipdb.set_trace()
Then I'll explore the context variables and figure out what the hell is going on.
I've spent a lot of time debugging Python over the years. This honestly never occured to me until you mentioned it.
Edit:
Everyone else jumped in before me. I think it would be useful as a command line switch to python to turn on the behavior (maybe call it extended exceptions).
Python would need to run the extended exception generation under a try/except that fell back to regular exceptions if an exception was raised while calling repr()
For instance any custom collection that acts as a decorator will now generate very large tracebacks.
I would have much preferred if the reraising with old traceback would have been a feature you can enable per site where you raise.
In [1]: try:
...: raise Exception('Something is wrong')
...: except Exception as e:
...: raise
...:
---------------------------------------------------------------------------
Exception Traceback (most recent call last)
<ipython-input-1-ef6cea2fccac> in <module>()
1 try:
----> 2 raise Exception('Something is wrong')
3 except Exception as e:
4 raise
5
Exception: Something is wrong
In [2]: try:
raise Exception('Something is wrong with RERAISE')
except Exception as e:
raise e
...:
---------------------------------------------------------------------------
Exception Traceback (most recent call last)
<ipython-input-2-c6729aaebd3d> in <module>()
2 raise Exception('Something is wrong')
3 except Exception as e:
----> 4 raise e
5
<ipython-input-2-c6729aaebd3d> in <module>()
1 try:
----> 2 raise Exception('Something is wrong with RERAISE')
3 except Exception as e:
4 raise e
5
Exception: Something is wrong with RERAISECorrect, and also you can explicitly suppress the other traceback now (3.2+)
I just wish it was the default unless you opted in. If I catch down an exception and raise another one I do not want the old one. Only in very rare cases am I interested in what lead to it. I have lots of hacks in Jinja2 now to hide useless tracebacks that would only confuse users.
For instance a jinja context tries different dicts through a chain in __getitem__. The naive implementation on Python 3 generates two nearly equivalent tracebacks that are very confusing.
(In case anyone missed it)
except foo.FooException as e:
raise BarException, BarException(e), sys.exc_info()[2]If we're going to get title changes, can we at least get useful title changes?
No. If the title changes were useful, what would we discuss on HN?
[Edit: thanks!]
In this case, "The most underrated feature in Python 3" was a fine title. It brought across the excitement of the post's author for this particular feature. I agree, it is a bit link-baity, but a much better version would be "Chaining exceptions is the most underrated feature in Python 3".
The current version ("An underrated feature in Python 3") is extremely nondescript, and I wouldn't have clicked it. It's almost like "A feature in Python 3".
If you object to the use of "most"... the author is obviously using hyperbole. There is no objective measure of "underratedness" of course. I wish people would not take everything so literally, and try to interpret a bit what they read instead. What the author wanted to say was probably (and this is an equally good title): "I really like that Python 3 has chained exceptions!"
Maybe, "Python 3 exception-handling improvement."