On 2 Aug 2017, at 20:40, yihao yang <yangyihao1...@gmail.com> wrote: > > What is the philosophy in golang error? I also saw a lot of packages have > their own Error override error interface. Why there is no shared Error > structure with a shareable error code? > > 在 2017年8月2日星期三 UTC-7上午11:36:11，yihao yang写道： > Hi, > > I found it is very difficult to judge an error in golang. For example, if I > want to judge a specific error returned by a function, but sometimes the > error is just newed by errors.New(xxx). > In those situations, should I just compare the error string to know what's > the exact error? Is that a go-way to do so? I'm a little confused.
In most cases you just care whether something succeeded or failed. If it failed you report the error and abort or continue down an alternative path. What the error was, exactly, might not matter. For the cases where it does matter, the package should provide a way to distinguish those errors. Typical ways to do this are comparisons against an example error (... == io.EOF), usage of a package level function (os.IsNotExist(...)), or asserting to an interface that provides additional methods (net.OpError#IsTemporary() for example). Having to care but not getting anything better to go on than the error string is a package design error. //jb -- 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.
