Should Console[F].printStackTrace reports stacktrace with tracing feature

[yanns]

CE provides a tracing functionality, given developers much more useful stack traces: https://typelevel.org/cats-effect/docs/tracing

When using Console[F].printStackTrace however, the tracing functionality is not used.

Should we use the tracing functionality for this?
Or should we provide another way to get access to those enhanced stack traces?

[vasilmkd]

We are working on it. This will be available through IO.trace sometime soon.

[yanns]

Thanks for the quick answer!
Duplicated of #2161 then

[vasilmkd]

I'll keep it open because we can still discuss the Console integration.

[Daenyth]

Related; will the tracing be visible in MonadError-based handling?

A common example would be:
I want to log.error an exception, and the exception would be received by a logback appender, which submits the exception to a tracking service (like Sentry).

That exception needs to have the tracing info

[vasilmkd]

@Daenyth Do you know if CE2 exhibits this behavior? If yes, CE3 should already support that.

[arosien]

Related; will the tracing be visible in MonadError-based handling?

A common example would be:
I want to log.error an exception, and the exception would be received by a logback appender, which submits the exception to a tracking service (like Sentry).

That exception needs to have the tracing info

I'd like a method to (idempotently) add the tracing info to an exception, rather than trying to ensure all code paths have the tracing upstream.

[Daenyth]

I'd like a method to (idempotently) add the tracing info to an exception

I'd really prefer the opposite. Out of the box behavior should be maximally useful; if the best practice is "every time you handle an exception, add the trace info", then that becomes a LOT of noise and bloat for application programmers.

@Daenyth Do you know if CE2 exhibits this behavior? If yes, CE3 should already support that.

To the best of my experience, yes CE2 fiber traces are basically "always on". It's always just worked. Specifically the behavior I mentioned of using onError, or handleError, or attempt, and passing the resulting Throwable to log.error (log4cats) has resulted in the stack traces including the fiber trace info (flatMap/map/etc)

[arosien]

I'd like a method to (idempotently) add the tracing info to an exception

I'd really prefer the opposite. Out of the box behavior should be maximally useful; if the best practice is "every time you handle an exception, add the trace info", then that becomes a LOT of noise and bloat for application programmers.

Yeah, you're totally right.

[djspiewak]

I actually think that, with the most recent changes @vasilmkd made, we don't really need this anymore. printStackTrace is more general than printing exceptions which involve Cats Effect traces, so I think it's better to keep it compartmentalized.