Extend stack to exc_info

[wujm2007]

I ran the following code (scripts/sth.py) and got reversed Traceback on sentry.

import raven

from config import SENTRY_DSN


def func():
    try:
        raise Exception('Dummy')
    except:
        raven.Client(SENTRY_DSN).captureException(stack=True)
        raise


def func2():
    func()


func2()

Raw Exception on sentry:

Exception: Dummy
  File "raven/base.py", line 406, in build_msg
    capture_locals=self.capture_locals,
  File "raven/base.py", line 624, in capture
    **kwargs)
  File "raven/base.py", line 799, in captureException
    'raven.events.Exception', exc_info=exc_info, **kwargs)
  File "scripts/sth.py", line 10, in func
    raven.Client(SENTRY_DSN).captureException(stack=True)
  File "scripts/sth.py", line 15, in func2
    func()
  File "scripts/sth.py", line 18, in <module>
    func2()

But I was expecting something like:

Traceback (most recent call last):
  File "/opt/project/fengmingx/scripts/sth.py", line 18, in <module>
    func2()
  File "/opt/project/fengmingx/scripts/sth.py", line 15, in func2
    func()
  File "/opt/project/fengmingx/scripts/sth.py", line 8, in func
    raise Exception('Dummy')
Exception: Dummy

I wonder if raven is designed to print Traceback like this:

• In reversed order
• Including how raven generate the output

Now I am using the hack in this page to bypass the problem, and I am wondering if there is a better solution.

[dcramer]

Sentry defines a spec on the order of frames. My instinct tells me this breaks that spec given how mature our Python SDK is. Additionally this would need tests to prove one way or the other.

[dcramer]

Aside it's possible our UI is generating the raw value in the wrong order but that would be unrelated to data collection.

[faith0811]

Hi wujm2007, dcramer

I did some research about this too.

def some_func():
    try:
        do_sth_raise_exc()
    except Exception as e:
        logging.exception(e)
        sentry_client.captureException()

The 2 lines in except block will output the same traceback, both these traceback will ignore the stack before the try block. Sentry does exactly what Python does in traceback function.

I think for certain reasons, the stack before try block should be ignored, otherwise there will be too much useless call info. Many of us wraps Sentry into a huge try .. except block as a middleware and the nature Python traceback function will protect us from too much framework call stacks.

But sometimes, I will make sure some important function in my code does not break no matter the running result and still be able to trace the errors. I will do a smaller try except and it might be as small as the code I given above. The information I can get from Sentry is short and useless. I want more info from stack above.

I think, one more optional params full_traceback to the Client.captureExcetion() will do the job, and have almost zero conflict to the current Sentry.

[dcramer]

I'm still not sure what your real goal is and this is missing many things to be accepted:

1. we'd have to agree this is an actual use case
2. it'd need to be fully tested
3. the API would need to be determined
4. it'd need documented

Either way, this is unrelated to the 'stack being reversed' which was the original description.