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 > <javascript:>> 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.
