3 ms·
You don't need Dave's package to get stack traces. All you need is the runtime package. How do you think Dave's package works? There is no error package, perha
by 4ad 10y ago
You don't need Dave's package to get stack traces. All you need is the runtime package. How do you think Dave's package works?
There is no error package, perhaps you mean the errors package. But it doesn't matter how you create your error in Go as long as you assert for behavior, because errors are interfaces. That is the point really.
If you import a package that uses Dave's error package, in general, you don't need to import Dave's package. That is the point of interfaces, to decouple things.
- nothrabannosir 10y agoThere is no error package, perhaps you mean the errors package. Of course (s)he does. Why even point that out...?
- xkarga00 10y agoWhy not? It's cool to point things out.
- twic 10y agoI suspect you've misunderstood TheDong's complaints. Firstly, "to reliably get error stacks" doesn't mean "to get stack traces"; it means "to get stack traces attached to errors". You do indeed need Dave's package, or some equivalent, for that; it's not something the standard way of creating errors gives you. Secondly, "this solution doesn't solve random third-party packages you depend on all that much since they'll still use the utterly useless std-library error package" doesn't refer to the situation where "you import a package that uses Dave's error package", but the converse - if you import a package that uses the standard way of creating errors, you won't get stack traces on those errors. That's true, and it's why Dave's package provides the Wrap function as a partial mitigation.
- tptacek 10y agoGo errors are not exceptions. It would not make sense to attach a stack trace to every one of them. If you want a stack trace, generate one when you return the error. It's hello-world simple.