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
{{ message }}
This repository has been archived by the owner on Dec 1, 2021. It is now read-only.
At the moment, there is no way to provide a custom stack trace for an error -- the stack trace is captured at Wrapf (or other such wrapping) time. While this is totally acceptable for pure-Go code, it would be useful to be able to add a stacktrace from a non-Go library which generates its own stacktraces.
The usecase that drives this is https://github.com/openSUSE/libpathrs -- it's a Rust library for which I'm writing some Go bindings. The fundamental cause of the error is within Rust code, but the Rust code provides (through C FFI) a full backtrace at the point the error occurred. Being able to produce loss-free Go errors would be pretty useful IMHO.
This proposal basically boils down to having something as simple as:
At the moment, there is no way to provide a custom stack trace for an error -- the stack trace is captured at
Wrapf
(or other such wrapping) time. While this is totally acceptable for pure-Go code, it would be useful to be able to add a stacktrace from a non-Go library which generates its own stacktraces.The usecase that drives this is https://github.com/openSUSE/libpathrs -- it's a Rust library for which I'm writing some Go bindings. The fundamental cause of the error is within Rust code, but the Rust code provides (through C FFI) a full backtrace at the point the error occurred. Being able to produce loss-free Go errors would be pretty useful IMHO.
This proposal basically boils down to having something as simple as:
The text was updated successfully, but these errors were encountered: