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.

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

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.

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.