Errors in Go aren't really used the same was as exceptions in other languages, and that's a good thing! Most of the time, all you care about is whether the error is non-nil or not. Occasionally you care about the specific type of error, in which case the package emitting the error should define a test method or constant to compare to (as with io.IsNotExit()). Beyond that, erros are just things you throw into your debug log. If it's useful to you to include stack information in the error message, you can do so. fmt.Errorf() is my usual method of formatting errors for such things.
I hesitate to mention this, since it leads to a lot of bad practice in my opinion, but if you want something that acts more like other languages' versions of exceptions, you can always use panic/recover... On Thursday, March 1, 2018 at 12:19:16 PM UTC-8, Tad Vizbaras wrote: > > It has been almost two years since this post: > https://dave.cheney.net/2016/06/12/stack-traces-and-the-errors-package > > What is current best practice? Should I use some package to gift wrap > errors in order to get stack trace attached to them? > > Standard library errors package is really "bare bones". Some guidance > would be appreciated. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
