For errors with stacks in golang today, you could try the Meep [1] library. It's a library for More Expressive Error Patterns. You can declare error types lik

For errors with stacks in golang today, you could try the Meep [1] library. It's a library for More Expressive Error Patterns. You can declare error types like this: type ErrFrobnozMalformed struct { Frob *Frobnoz meep.TraitTraceable } ... and any type you compose with a meep trait like that gets superpowers, like automatically attached stacks. I'm the author. I don't think it's perfect -- in particular you really can't avoid a certain amount of boilerplate :( -- but with meep you get stacks, and you get custom error types, and that's worth a lot to me. Whether or not you use this code, the idea that might be a useful takeaway is the fact that the stack-capturing behaviors (and others) are a trait that you can "mix in". Whether a stack is appropriate depends on situation. Some errors are fairly regular (e.g. certain kinds of IO halt) and putting a stack on them is not useful (and is CPU-costly). This doesn't necessarily follow any sort of direct inheritance tree. (Java has started doing something similar with adding Even More parameters to exception constructor for e.g. 'capturestack=false'.) I think this is an important point: errors often should have stacks, but not always. I'm still hugely looking forward to seeing what the Go authors do in the future to make errors smarter. Doing the right thing should be easy, and it's almost impossible to strap something this essential on with a library: special syntax and compiler support for informative errors is warranted. --- [1]: https://godoc.org/github.com/polydawn/meep https://godoc.org/github.com/polydawn/meep