Hacker News Reader

Comment by the_mitsuhiko | Hacker News Reader

To be honest. As cool as this feature is in the 1% of cases where I wanted it, so annoying is it in 99% of all other cases. Tracebacks on Python 3 became a lot more complex because very often exceptions are intentionally swallowed to be reraised differently and they just mess up the traceback now.

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.

View on HN

I don't understand what are you talking about. AFAIK, you don't have to reraise the previous exception:

    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 RERAISE

> I don't understand what are you talking about. AFAIK, you don't have to reraise the previous exception:

Correct, 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.

If you don't want the older exception, why are you giving it to the constructor of the new exception?

Just raise SomeErrorType("error message"), and it will not polute your traceback. Raising SomeErrorType(anotherError) is there for when you care about anotherError.

> If you don't want the older exception, why are you giving it to the constructor of the new exception?

Exceptions are chained automatically through the stracktrace and not because they are passed to the constructor. By raising an exception from an exception handler you automatically chain them.

I don't think Jinja is a relevant example here - it's not something people usually write. While you take great care about the API and error handling most other people are sloppy and their code is hard to debug because they unknowingly cripple the tracebacks. That's why I like this feature just the way it is (an opt out, instead of explicit opt in) - cause it needs to cater for the 99% of the people who didn't even bother to reraise properly in Python 2.

Reply on news.ycombinator.com