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
Early versions of Kyo used to have a mechanism to present better stack traces, similarly to other effect systems, but evolving Kyo while considering how to do that efficiently got difficult so I decided to remove the feature.
At the time, the solution used to use an allocationless macro to generate frame information as constant strings at compile time. It was quite efficient but I felt it was too intrusive. The frame implicit has to be included in virtually all of Kyo's methods since it should come from the user's code.
I think we could go with a solution similar to cats-effect by dynamically inspecting the JVM's stack trace to capture frames. We should use StackWalker to find the origin frame in the user code given that it's much more lightweight. The mechanism would introduce more overhead than the previous static one so I think it'd need to be disabled by default.
The text was updated successfully, but these errors were encountered:
I played a bit with StackWalker but the overhead is too high, it wouldn't be viable to use in a production environment. I'm going with a macro similar to ZIO's #413
Early versions of Kyo used to have a mechanism to present better stack traces, similarly to other effect systems, but evolving Kyo while considering how to do that efficiently got difficult so I decided to remove the feature.
At the time, the solution used to use an allocationless macro to generate frame information as constant strings at compile time. It was quite efficient but I felt it was too intrusive. The frame implicit has to be included in virtually all of Kyo's methods since it should come from the user's code.
I think we could go with a solution similar to cats-effect by dynamically inspecting the JVM's stack trace to capture frames. We should use StackWalker to find the origin frame in the user code given that it's much more lightweight. The mechanism would introduce more overhead than the previous static one so I think it'd need to be disabled by default.
The text was updated successfully, but these errors were encountered: