Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

errors: Allow custom StackFrames #43

Closed
alexanderwilling opened this issue Dec 15, 2016 · 1 comment
Closed

errors: Allow custom StackFrames #43

alexanderwilling opened this issue Dec 15, 2016 · 1 comment

Comments

@alexanderwilling
Copy link
Contributor

alexanderwilling commented Dec 15, 2016

I'd like to send errors with stack trace information to Bugsnag after serializing and deserializing them. For that, I need to be able to create an errors.Error variable outside of the runtime where the error occurred. Currently, if I understand correctly, it's impossible to "rebuild" the stack frames after deserializing, because that's done by interacting with the runtime using the program counter.
I'd like to introduce a

type ErrorWithStackFrames interface {
    error
    StackFrames() []StackFrame
}

which would then be included in the type switch in New. Error.stack would be set to nil, and Error.frames would be populated from the ErrorWithStackFrames.StackFrames() method.

The documentation of the Error.Callers() method would need to be updated to tell users it might return nil, but it's not used in the package itself and I'm not sure who would be using this in the first place. The Error.StackFrames() method would work just like before.

Let me know if you want me to prepare a pull request for this feature, or if it's not something you want to support.

@kattrali
Copy link
Contributor

Hi @alexanderwilling, thanks for the thoughtful enhancement suggestion.

Currently, if I understand correctly, it's impossible to "rebuild" the stack frames after deserializing, because that's done by interacting with the runtime using the program counter.

Correct. I think your proposal makes sense for other use cases where the program counter is not available.

The documentation of the Error.Callers() method would need to be updated to tell users it might return nil, but it's not used in the package itself and I'm not sure who would be using this in the first place.

ErrorWithCallers exists for consumers of https://github.com/go-errors/errors.

I think your proposal is good. If you’d like to discuss over a pull request, I believe the only required changes would be to add the interface and add a case for it (similar to the one for ErrorWithCallers). Though perhaps it would be helpful to add an example usage to the examples dir so it can be referenced from the docs. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants