3 ms·
I'm aware of stack traces on panics, but my understanding is you only get them if you let them bubble up and kill the application (so not really a "first class"
by BoorishBears 6y ago
I'm aware of stack traces on panics, but my understanding is you only get them if you let them bubble up and kill the application (so not really a "first class" option for errors in places like web handlers) Has that changed, or did I misunderstand?
But I also think the stack trace message example is the perfect example of what I mean by "take the Go mentality with you"
In a language like Kotlin for example, Go got my in the habit of attaching more information to exceptions as they bubble up.
I was already generally in the habit of wrapping library exceptions, but I started religiously using a Result nomad implementation and wrapping errors with additional information so that my stack traces looked very "Go-like" in terms of human readability, but kept traditional stack trace information.
It's small things that I think using Go makes you "re-appreciate" in other languages
- hcles 6y agoYou can get the full stack of the crash point (and a few extra frames that handles the stack generation) in a deferred recover, ie https://play.golang.org/p/XvZteY6Y6fh https://play.golang.org/p/XvZteY6Y6fh github.com/pkg/errors is a simple way to dump expensive stacktraces into each new/wrapped error. Or you can just panic and recover in your own app, it's possible though discouraged.