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
When watching @adamw's recent talk where he compares the usability of direct-style approaches to plain ZIO, I was a bit surprised to see that he argued that ZIO's stacktraces are only "basic". In particular, I was surprised about ZIO's behaviour in this example.
I experimented a bit to understand the behaviour better and found that the stacktrace only contains the "frames" of the left-hand side of a flatMap. Here is an example to show the issue:
//>usingscala3.4//>usingdepdev.zio::zio:2.0.22importzio.*objectPrintsStacktraceextendsZIOAppDefault:defrun= a
defa= b.flatMap(_ =>ZIO.unit)
defb= c.flatMap(_ =>ZIO.unit)
defc=ZIO.fail("The failure")
This prints:
timestamp=2024-04-15T09:50:00.275792Z level=ERROR thread=#zio-fiber-1 message="" cause="Exception in thread "zio-fiber-4" java.lang.String: The failure
at <empty>.PrintsStacktrace.c(PrintsStacktrace.scala:10)
at <empty>.PrintsStacktrace.b(PrintsStacktrace.scala:9)
at <empty>.PrintsStacktrace.a(PrintsStacktrace.scala:8)"
which includes the helpful info on where the effects where constructed.
Here is the example where we do not get helpful output:
//>usingscala3.4//>usingdepdev.zio::zio:2.0.22importzio.*objectNoStacktraceextendsZIOAppDefault:defrun= a
defa=ZIO.unit.flatMap(_ => b)
defb=ZIO.unit.flatMap(_ => c)
defc=ZIO.fail("The failure")
which prints
timestamp=2024-04-15T09:51:59.317835Z level=ERROR thread=#zio-fiber-1 message="" cause="Exception in thread "zio-fiber-4" java.lang.String: The failure
at <empty>.NoStacktrace.c(NoStacktrace.scala:10)"
I am not sure if this behaviour is intentional, but I agree that this is not ideal from a usability standpoint, because we are missing valuable information to locate the failed effect.
The text was updated successfully, but these errors were encountered:
@jdegoes just want to add a requirement to this ticket if possible?
Fixing this can negatively impact performance of the runloop depending on the implementation. I'm actually not sure if it's even possible to fix it without impacting performance to some degree.
I thin any attempted solution should either :
Provide before/after benchmark results of the NarrowFlatMapBenchmark and BroadFlatMapBenchmark suites (at the very least) showing that the runloop performance wasn't affected, or
Perhaps create a runtime flag (disabled by default?) to enable detailed stack traces
When watching @adamw's recent talk where he compares the usability of direct-style approaches to plain ZIO, I was a bit surprised to see that he argued that ZIO's stacktraces are only "basic". In particular, I was surprised about ZIO's behaviour in this example.
I experimented a bit to understand the behaviour better and found that the stacktrace only contains the "frames" of the left-hand side of a
flatMap
. Here is an example to show the issue:This prints:
which includes the helpful info on where the effects where constructed.
Here is the example where we do not get helpful output:
which prints
I am not sure if this behaviour is intentional, but I agree that this is not ideal from a usability standpoint, because we are missing valuable information to locate the failed effect.
The text was updated successfully, but these errors were encountered: