So I guess another way of phrasing this question is, is this post gospel: https://dave.cheney.net/2016/04/27/dont-just-check-errors-handle-them-gracefully
If so, is there a plan to backport this into the whole standard library? Regards & Apoligies Chris On Monday, 2 October 2017 13:51:24 UTC+1, Chris Hopkins wrote: > > Yes, it has dynamic type. That doesn't mean you can't test against it. > I thought the preferred way to to handle errors was for a package to > expert the error variables, then you could test for those variables as in > the above code. > > For the packages that don't do that you can call Error on the error > interface and get a string which you can then search through to reverse > engineer the error. But that's a horrid way to do it and IMO is the sign of > a broken package. > > Maybe I'm doing this all wrong, but there is very little documentation out > there I've found on how to actually HANDLE errors in go. Having just > googled it, out of the top 10 hits on "golang error handling" only 2 of the > hits actually talked about how to work with an error's value rather than > some version of "oops something has gone wrong, return the error for > someone else to deal with". > > Chris > > On Monday, 2 October 2017 13:35:27 UTC+1, Jan Mercl wrote: >> >> On Mon, Oct 2, 2017 at 2:19 PM Chris Hopkins <cbeho...@gmail.com> wrote: >> >> I'm not sure I understand: error is an interface and it always has some >> dynamic type when non-nil. But that type cannot by string b/c string does >> not implement the error interface. >> >> -- >> >> -j >> > -- 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.
