Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What's the use case for exception.escaped? #1516

Closed
trask opened this issue Oct 24, 2024 · 5 comments
Closed

What's the use case for exception.escaped? #1516

trask opened this issue Oct 24, 2024 · 5 comments

Comments

@trask
Copy link
Member

trask commented Oct 24, 2024

What's the use case for exception.escaped?

We have never captured this in Java instrumentation, and no one has ever asked for it, so I'm wondering if it's really useful?

Assuming there are use cases for it, are they compelling enough to justify capturing it by default (as recommended) or should it be opt-in?

@scheler
Copy link
Contributor

scheler commented Oct 25, 2024

The trace sdk in python seems to be setting this attribute to True automatically - see this - and a relevant example would be the following - .

try:
    with tracer.start_as_current_span("example-span") as span:
        print("Inside the span.")
        # Simulate an operation that raises an exception
        raise ValueError("An intentional error within the span.")
       # the span automatically ends here but the exception lives on
except Exception as e:
    print(f"Exception outside span: {e}")
    # Exception can propagate here after the span is closed
    raise

The documentation for recording an exception has a pseudo-java example - maybe we should replace it with the python example? The Java example still demonstrates the purpose of this attribute.

@trask
Copy link
Member Author

trask commented Oct 25, 2024

thanks @scheler

I think the question I'm trying to ask is what would a user do with this piece of information (exception.escaped)? and is that use case compelling enough to justify capturing it by default (as recommended) or should it be opt-in if it's a very narrow use case

@scheler
Copy link
Contributor

scheler commented Oct 25, 2024

@trask I think the python community would know more on this since the spec language for this attribute includes python terms and is likely written by someone from python side. (ContextManager / exit method).

@lmolkova
Copy link
Contributor

I was making a case for this attribute in open-telemetry/opentelemetry-specification#4333, but I no longer think it's necessary.

I believe the use-case behind it is the ability to distinguish handled exceptions from unhandled ones.

If we report exceptions on logs/events, we have severity to capture it - Error+ severity is for exceptions that went unhandled and wither failed incoming call, background operation, or crashed the process. Warning and lower is for exceptions that are being handled or may be handled by the caller.

there is no severity on the span event and we should deprecated this attribute along with span events.

@lmolkova
Copy link
Contributor

The attribute is now deprecated in #1716

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants