You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you call recordException on an exception caught with catchAny or similar, you will get an uhelpful exception.type, namely SomeException itself. What you really want is the type of the inner exception. We can get this, we just have to unwrap it.
In general, I'd like to add support for the TracerProvider to register exception enrichment functions that can do unwrapping, add attributes to the exception events, etc. In particular, we use annotated-exceptions, which is yet another one of these wrappers.
I do agree with teaching registerException what to do there, but ideally it would be somewhat extensible instead of hardcoding to the lowest common denominator in the extensible exception hierarchy.
That sounds like it's going to require quite a bit more design work. I think at least handling SomeException would be useful for users in the short term. I don't tremendously mind - if we want to do it properly I'll just write the wrapper in my work codebase!
If you call
recordException
on an exception caught withcatchAny
or similar, you will get an uhelpfulexception.type
, namelySomeException
itself. What you really want is the type of the inner exception. We can get this, we just have to unwrap it.We do this ouselves in the codebase: https://github.com/iand675/hs-opentelemetry/blob/main/api/src/OpenTelemetry/Trace/Core.hs#L395
I think we should just teach
recordException
to do this itself. Perhaps just callcast
to see if it's aSomeException
, and if so unwrap it?The text was updated successfully, but these errors were encountered: